I'm wondering if this is what you meant to say. Unit tests are the most effective when they're 100% deterministic. Getting there usually requires using predetermined test data, and some careful use of mock objects to return deterministic values.
Taken to extreme lengths, this can involve switching in a mock implementation of time() that's under the control of test code, so that you can control the advancement of time (figuratively, of course).
I had to put my design on paper. This may be the most important aspect of TDD.
This may be one of those YMMV (Your Mileage May Vary) things. I've found no difference in the need to have a couple of good drawings of the system architecture (as it evolves) between doing TDD and not doing TDD. With TDD, you're forced to confront interfaces early, and you're encouraged to not build more than you need for the story at hand. This encourages lean design, which I've found to be cleaner than a "grand up-front design". On the other hand, unit tests often require using delegation (to be able to swap in mock implementations), which does add a layer to the design. Having a picture might help.
[TDD] definitely forces the developer to design things so that they can be verified.
Exactly.
In reply to Re: TDD: a test drive and a confession
by dws
in thread TDD: a test drive and a confession
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |