Anecdote Driven Development, or Why I Don't Do TDD | Hacker News Reader

Anecdote Driven Development, or Why I Don't Do TDD

use.perl.org

39 points10ren11 comments

TDD is one approach, and like most approaches when it comes to creative acts (writing, painting, whatever), different approaches are a fit for different people.

Tests are crucial to maintaining quality over the long term and to preserving your ability to refactor and change the code. How you arrive at those tests (test-first, test-last, test-randomly) is much more a matter of personal taste. Part of maturing as a programmer is learning what works best for you.

I use a mixture. If it's a Java method, I use test-after, by which I mean after the method is written, some times after the core of the class. Most of the time I am not working from specs, so I find TDD interrupts the design/implementation flow. Often I dont know the complete signature until I have written it. If the method is complex, it often gets a couple of refactorings along the way.

The case where I consistently test before is a method doing database queries. I find it much less tedious to write and test pure SQL before any java.

SQL has a lot of parallels to dynamic languages like Smalltalk. Both have strange loops. SQL tables have their meta-data stored in yet another SQL table. (System dictionary.) All Smalltalk objects have their behavior stored in another object, its class. The class of any class is Class. Class also has a class, named Metaclass. The class of Metaclass is itself.

While I enjoyed the article, I think the author, like many others, misses or misrepresents what the purpose of TDD is.

He argues that doing TDD is not an effective test strategy and he seems to have a valid point. However, TDD is not about testing, but about design. TDD's claim is that it will guide you towards a better design by allowing you to explore design possibilities, forcing you to think about the responsibilities and collaborations involved. Catching bugs is one of many things you get as a bonus, but it is a bit of an afterthought.

This is a common misconception, but I think it ought to be pointed out.

I don't think the author has any such confusion. He talks about testing to emphasize that he is strongly in favor of testing, but he found TDD as a development model lacking.

He may be a bit slopping in using "the testing world" when he means "advocates of TDD", but his specific claim is that TDD makes it harder to explore design possibilities than the alternative of what he calls exploratory coding.

From the conclusion:

So for the time being, I'm quite comfortable with my testing approach. I've given up on "pure" TDD of writing one test at at time. I'll happily write a block of tests and then the code. I'm also happy to write a block of code and then the tests. I can now even cite a study to show that I'm not a complete moron, even if one study is little more than anecdotal information.

The title is somewhat misleading; it's a discussion of test first vs. test last, not testing vs. not testing.

The title isn't "Why I Don't Do Testing", but "Why I Don't Do TDD". Test-driven development is explicitly test-first.

Agreed and understood. But for better or for worse, TDD is often used as a synonym for unit testing.

And unit testing is frequently used as a synonym for automated testing (at least thats my experience).

Can anyone find the original paper? The nrc doesn't seem to be hosting it any more.

If you're an IEEE member, you can get it here: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1423...

It's interesting, though, that the author makes it seem like this paper is the only research on the efficacy of TDD. Even a cursory search of Google Scholar turns up a number of papers:

http://scholar.google.com/scholar?hl=en&lr=&q=%22tes...

Including a 354-page doctoral dissertation that studied both students and professionals over a 5-year period [PDF]:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94....

I haven't read the dissertation, but the abstract seems to contradict the OP: "This research demonstrates that software developers applying a test-first (TDD) approach are likely to improve some software quality aspects at minimal cost over a comparable test-last approach. In particular this research has shown statistically significant differences in the areas of code complexity, size, and testing. These internal quality differences can substantially improve external software quality (defects), software maintainability, software understandability, and software reusability. Further this research has shown that mature programmers who have used both the test-first and test-last development approaches prefer the test-first approach."

Reply on news.ycombinator.com