Sunday, January 27, 2008

Personally, I have used and I enjoy Test-Driven Development, which is a software-developer process involving writing unit tests before your write code. At the same time, the 'Agile' community has seen a lot of buzz about ... something else, involving getting tests-before-code as examples. I am perfectly fine with this as an augment to requirements, but I don't think it is a replacement, and that does not mean you can turn your brain off because the tests written before the code is developed all pass.

As always, I am impressed by James Bach's ability to take the issue I'm struggling with, put it on the table, and take a stand. Here's an exerpt from one of his more recent posts:

Thinking about how to test a product is a fine thing to do at any time, but I find that developing specific and detailed test procedures from a spec usually leads to poor testing. This is because testing and development is a learning process, not just a doing process. A big part of the learning comes from building the thing and playing with it as it is being built. Even a spec that is very good (and very few are much good at all) does not teach you all that you need to know to conceive of good tests, and even if it did, you can't know that all the good testing ideas have occurred to you early in the process.

Anyone, not just you, who says that "test-first" is a viable strategy needs to do more than just claim experience. You might as well be claiming to have seen Bigfoot. Okay, maybe you have seen him, but what we need is a set of detailed experience reports.

The XP people *have* supported their claims with detailed experience reports, demonstrations, etc. But the part of the testing problem they address is a small fraction of the whole.

The people I've heard who advocate test-first on a system scale (rather than unit-scale), including people who push that interpretation of the V-model, have not, to my knowledge, showed that their method is workable. I'm not even sure what they think they mean by the word "test", but it doesn't seem to match how I think of testing.

3 comments:

Test-first doesn't mean test early where you write all tests before all code that makes the test pass. You should write the tests for a particular feature followed by the feature. Then write some more tests for another feature and so on. In tight loops. This is true on a unit scale or system scale.

This way you are writing tests at the Last Responsible Moment and so all the learning obtained during the process is incorporated into the tests.