Design in TDD
There’s been a recent discussion in the Melbourne XP Enthusiast Group (MXPEG) mail list about whether or not TDD ‘works’, with part of the thread also being about Story Driven Development (SDD). Some of the folks have reported a lot of success using SDD and its associated tests (that I would call acceptance and integration tests), to the point where they don’t use unit tests at all. The impression I get is that with this approach they’re working predominantly top down. I’m glad this works for some people, but I don’t think it would work for me, and I wanted to take a few minutes to say why.
I think it’s important to have both unit tests (developer tests) and acceptance tests (customer tests), whether they’re implemented in the same tools by the same people or quite different tools by quite different people. Notice though that I said “implemented” – to me the two groups of tests have different owners, different perspectives, and serve different purposes.
Customer tests – they tell us if the application is sick or not, but they don’t provide any indication of where or why.
Developer tests – they tell us exactly where something is going wrong, but don’t necessarily tell us what the impact on the overall application would be.
I would like to have both of these, not one or the other. I also find that I personally don’t design entirely either top down or bottom up. I do some top down stuff to get an idea of the problem, then I use that to hypothesise about a design that will meet the requirements. Once I have some confidence that my design looks reasonable, I implement parts of it bottom up, and I want unit tests to confirm that my implementation of each component works the way I expected. I keep switching back and forth between top down and bottom up as I go.
The thing I do badly is that I don’t write acceptance tests until the end (if at all). I know this isn’t what I’m supposed to do, I know it probably detracts from my overall quality, but it is what I find myself doing. So far I haven’t found a tool that makes writing those tests easy enough for me (personal opinion only).
I’m not sure of the original source, but a colleague shared with me this gem the other day:
“Unit and Integration tests help us build the application right.
Acceptance tests help us build the right application.”
This thread on mxpeg has come at an interesting time. I’ve never seriously tried acceptance tests-first, but I’m putting a big effort in at the moment to get it going on my current gig. Should be interesting.
“to the point where they don’t write unit tests at all” scares the willies out of me…
I like that expression of the distinction between acceptance tests and other tests.
I’m very interested in the tools that people use to express and encode their acceptance tests. I’ve seen Selenium and Junit used (neither was particularly accessible to the customer), and I’ve heard people praise Fitnesse, but I don’t seem to be able to grok it.
The main thing seems to be that when I hear “acceptance test” I expect it to drive the application through the user interface, and that’s not how Fitnesse seems to work. Fitnesse looks more like integration testing to me, coming in one level below the UI. But I’d be really happy to be wrong, and have someone give me a demo of how they use Fitnesse, or a similar tool.