TDD is BS?

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Jun 20 18:03:35 PDT 2013


On Thu, Jun 20, 2013 at 06:37:35PM -0400, Nick Sabalausky wrote:
> On Thu, 20 Jun 2013 21:38:08 +0200
> Jacob Carlborg <doob at me.com> 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!


More information about the Digitalmars-d mailing list