On Thu, Jun 20, 2013 at 06:37:35PM -0400, Nick Sabalausky wrote: > On Thu, 20 Jun 2013 21:38:08 +0200 > Jacob Carlborg <[email protected]> wrote: [...] > > You don't write all the test at once and then all the > > implementations at once. Write tests for one function first, then > > implement it. Then move to the next function. > > > > Also, tests are not written in stone. They should evolve and change > > just as much as the rest of the code. > > > > But then at that point, where's the benefit of writing the tests > first? > > I can still evolve/change the tests if I wrote them after the > implementation. Writing them before the implementation just means I > have that much more bookkeeping *while* implementing. May as well just > hold off on the tests until I have an actual interface to test > against. It not like the pre-written-but-failing tests were doing me > any good while I was still implementing. > > I'm not saying that it's necessarily bad to write a function's tests > before the function itself, I just don't see what it really matters to > code the tests first. The important thing is that the tests get > written, ideally before you move on to something else. If you have the > discipline to write the tests before the function, then you have the > discipline to write the tests after the function. > > If the issue is to make sure the tests promptly get written promptly, > then D's built-in unittests do far more to encourage that than TDD > would seem to.
+1. I'm guessing that part of TDD's drive is that you want to be explicit about what you expect from your code, so you set down your expectations beforehand; and since you have to do that, why not do it in the form of actually-runnable code (i.e., unittests)? Then, you work on making the code behave the way you expect. I have no problem with the bit about setting down expectations of what the code should do -- it may help you rethink the problem from the POV of the user of your code, and possibly find better ways of structuring the solution. But where I see TDD treading shaky ground is to singlemindedly focus on this part of the coding process to the exclusion of all else -- algorithm design, correspondence between API and implementation, efficiency considerations, etc.. I've always been a supporter of the view that the best programs are those in which code structure corresponds with data structure (a key idea in Jackson Structured Programming). Focusing on API design to the exclusion of everything else risks a mismatch between API structure and implementation structure, which leads to increased likelihood of bugs, inefficiencies, and code smells. T -- IBM = I'll Buy Microsoft!
