On Thursday, 20 June 2013 at 12:16:54 UTC, deadalnix wrote:
On Thursday, 20 June 2013 at 10:13:53 UTC, Jacob Carlborg wrote:
On 2013-06-20 00:47, Nick Sabalausky wrote:
- Writing a unittest first forces the API to be designed
before the
implementation is written. But implementation is necessary
to flush
out unexpected design requirements (If you think you can
always
come up with an appropriate design and interface before
implementing, then you're just plain wrong). Sometimes the
appropriate design and API is obvious. Sometimes it isn't.
When it
isn't, then TDD skirts dangerously close to some of the
problems of
"Waterfall Model". Sure, TDD advocates
refactoring-as-needed, but I
can do that with or without TDD.
Just because you have written a test doesn't mean you cannot
change it. Perhaps you come up with a better API design, then
change the tests.
When I start something, it isn't always clear what mental model
of the problem fit best the problem. I usually wait until I
know I have a consistent mental model of the problem to write
test. Otherwise, tests tend to get into your way to change the
API( because you need to change tests as well. I start writing
test when I know what kind of API make sense (it isn't always
finished, but I know what it will look like overall).
Which lead to TITMOD, test in the middle of dev.
You should write a book on that, it'd be a total paradigm shift
for the non-yet-believers of TITMOD.
