3 ms·
The thing that bothers me the most about TDD is that it really seems to mean unit test driven development. Unit testing has its place, to be sure, but it is onl
by Chris_Newton 16y ago
The thing that bothers me the most about TDD is that it really seems to mean unit test driven development. Unit testing has its place, to be sure, but it is only one tool in the box.
By its very nature, unit testing will always be limited to checking simple, well-defined, low-level behaviour. There is no unit test to tell you that you made a good choice of data structure or algorithm. There is no unit test to tell you that your domain model is sound and relevant. There is no unit test to tell you that your calculation code is a faithful implementation of incorrect mathematics that you thought was correct. There is no unit test to tell you that your requirements were the result of poor analysis and as a result you're building a product your customers won't buy.
If we take a single tool like this and elevate it to the point where the entire development process is built around it, then must the process itself not be limited as well?
The TDD community seem to compensate for this by adding the well-known third step:
1. Fail.
2. Pass.
3. Magic happens.
During that final step, we have an opportunity to compensate for any failure of the small-increments, simplest-thing-first approach to converge efficiently on a good end result. This in itself doesn't seem unreasonable, but I have never seen a single piece of TDD advocacy or training material that explains how this is supposed to happen, at least not in any serious detail or in any form that is amenable to training developers in how to do it.
The trouble is, almost all of the hard stuff in programming is in areas that unit tests don't address, such as those I mentioned above. That being the case, the whole TDD process can also only address the easy stuff until the "refactoring" step is explored in very much more detail than it has been so far. I think perhaps this is what Michael Feathers is starting to realise and trying to highlight in this article.
- jamesbritt 16y ago"There is no unit test to tell you that your requirements were the result of poor analysis and as a result you're building a product your customers won't buy." No, but that's why there is integration and acceptance testing, and the sooner you get feedback from actual users the better off you are. TDD doesn't have to mean unit tests.
- Chris_Newton 16y ago> TDD doesn't have to mean unit tests. Really? I'm not sure I've ever seen any TDD-related source claim that the tests that initially fail and are then made to pass are anything but automated unit tests.
- steveklabnik 16y agoGenerally, you write an acceptance test, watch it fail, drop down into the unit tests that get your code going, pull back up into your acceptance test, move on to the next part... Here, I wrote something about this: http://timeless.judofyr.net/bdd-with-rspec-and-steak http://timeless.judofyr.net/bdd-with-rspec-and-steak Most of these are not 'unit' tests in the traditional sense of the word. Unit tests are useful, but only as part of a larger testing strategy.
- Chris_Newton 16y ago> Unit tests are useful, but only as part of a larger testing strategy. I agree, but I think you're making my point for me. TDD and unit tests alone are not enough, which motivates further developments like BDD. I think we can apply an analogous argument even to a BDD process, because there are many advantageous properties code might have that can not be determined effectively using a finite number of specific, automated, behavioural tests, no matter what level of abstraction those tests run at. Your BDD process is not as limited as TDD, but it still contains a "magic happens" line, "Refactor code as appropriate."