开云体育

I've been away from serious OOP programming for a while, working in Prolog, etc. So now I'm back, using VS2013, and starting development with a large CAD API. My TDD experience has followed the

Starting with acceptance tests is a great idea. So is starting with high level unit tests, mocking the details, and then working your way down. Also, sometimes if I think I know what the essence of

Michal, I write acceptance tests all at

Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote: Hi Kaleb, I hear what you are saying. But it really goes down to that gut feeling. Sometimes I want to see the whole story

[testdrivendevelopment] <testdrivendevelopment@...> wrote: Please do. Feel free to e-mail me or post a link to the writeup once it's done :). --Kaleb

[testdrivendevelopment] <testdrivendevelopment@...> wrote: I remember seeing that post but I forgot to respond -- that's a good idea that I've never tried. Done properly that should

Hi Kaleb, As others have said: Change gear depending on your experience wit TDD and comfort in the situation. There's a another point to be made though. Ron and Chet emphasized in their CSD

teaching is using Java and moving a method from a static call no a non-static call. The test suite now needs to be updated in multiple places, hence the duplication. If the entire test is written up

Kaleb, If you insist (as an earlier poster did) that you first write an assert, then you would avoid this “compilation only” worry (as long as your assert is non-trivial). John D. Sent: 28

[testdrivendevelopment] <testdrivendevelopment@...> wrote:

[testdrivendevelopment] <testdrivendevelopment@...> wrote: I think you've just described my biggest concern with writing the entire test up front. When the entire test is written up front

Thanks for the feedback Jeff. In thinking about "green" tests and the process taken with TDD, I think it boils down to the fact that the name of the test should represent the goal for the test. Along

Answers inline. Again I would put that down to duplication. It's extreme, but if I call a method from 15 tests I see that as something that should be extracted

I would always do this when leaving for the day, mostly as a way of reminding myself in the morning what I was working on [testdrivendevelopment] <testdrivendevelopment@...> wrote:

A rule of thumb I followed for many years was to leave a failing test when taking a break. Charlie [testdrivendevelopment]" <testdrivendevelopment@...> wrote:

Never trust a test you have never seen fall. Tests can pass for the wrong reasons. You have to trust then or get rid of them. That said, there are intermediate steps which are legitimately green

I think all the answers have been wise and sensible. But then, I think the answers all come from “Ha” or “Ri” practitioners, and I suspect Kaleb was talking to “Shu” people. (If you are

Exactly. You should only commit the test after you've gone through the full Red-Green-Refactor. In fact, assuming you're using DVCS or your own branch, I would go so far as to say that you should

You might want to consider the difference between a test during development locally and a test that have been checked in to the common repository. I have been confused by tests with names saying they

Kaleb Pederson kaleb.pederson@... [testdrivendevelopment] wrote: Either approach you described can be justified. Test that just contains one variable is actually complete and says "the object