No matter whether you call it Test Driven Development or Test Driven Design, many people now accept that the use of the word test is at best misleading and at worst can result in fundamental misunderstanding of what TDD is about.
TDD at its core is the process of defining expected behaviour of your code,make your code match the expected behaviour, refactor, and so the cycle goes. The problem is that presently the only way we have to define the expected behaviour is using test tools such as JUnit. I’ve lost count of the number of people who have become confused over TDD, and have ended up thinking that because their code was developed using TDD that its fully (unit) tested – its not, you just wrote enough tests (specifications) to drive out the behaviour of the system.
We need a new name – call it Behaviour Driven Design, or Specification Driven Design or whatever you want (I’m sure I’m not the first person to use either terms). We need new tools – as long as we use unit testing tools to specify behaviour people will still get confused about what they are actually doing. Even a JUnit clone with different names would go a long way to fixing the misunderstanding. I am of course being slightly disingenuous on that final point – I know some new tools are coming. But without a better understanding of what Specification/Behaviour Driven Design is really about, the new tools will be pointless.
magpiebrain 
6 Responses to “It’s time to drop the ‘T’ from TDD”
I dunno… something which defines behaviour and can verify that the behaviour is met sounds a lot like a test to me.
Tests (at least in the way JUnit does it) do _not_ define behaviour – all they do is check returned values. They do not define expectations, and cannot verify the calls made to other objects.
The real point though is that people think of code that has been written using TDD as being fully tested, which it isn’t. You can easily drive out a design using a few tests that do not neccesarily cover all corner cases that might arise.
TDD is more about the psychological process of creativity than about testing or formal specification. I agree with your point, which I would restate as: people tend project their own assumptions and desires onto the TDD methodology and JUnit, being a unit test framework, makes it all the more tempting to project that their code is thoroughly tested if they used JUnit and TDD.
On the other hand, Kent Beck, R. Martin and Erich Gamma do have an uncanny ability to demonstrate near 100% code coverage (at least method and usually statement) in their books and articles promoting TDD via JUnit.
I wouldn’t fault JUnit and TDD too much though. What Beck did that is so valuable is to demonstrate a better way to create software through inverting the *thinking* process. Beck is one of the few I know of in this field who takes the programmer’s mind into consideration and realizes that it is the thinker at the keyboard who we need to work with and understand, and we need to understand the thinker as a human being and understand how that mind works to leverage it. Beck “gets” this deeply — most people do not.
Code coverage does not bug free code make – just because a line of code has been covered, does not mean it has been tested fully. Beck’s strongest point for me is that when we write code without having a means to define how it should work or its expected behaviour, we are guessing that it works. By actually verifying the behaviour programatically (be it by using xUnit, Mocks etc) we are instead asking the computer to confirm our expectations – and they are far less error prone than we đŸ™‚
On the code coverage front, you might want to look at something like Ivan Moore’s “Jester”:http://jester.sourceforge.net/ – it changes your code at the source level and runs tests – if the tests still pass it reports it. That can help pick up things that are tested, but perhaps badly tested (in that changing the codes behaviour doesn’t test the test results).
Hi Sam,
Did I say code coverage made for bug free code? Look again. Code coverage analysis is a staple of sophisticated quality assurance, but not the only thing of course. I have used Jester (useless piece of shit, IMO), JProbe Coverage, OptimizeIt Coverage and Clover. Overall, I recommend Clover because out of all of them, it’s the easiest to automate with Ant and it makes various pretty reports useful for developers and appealing to managers.
What you said about Beck and defining behavior is totally agreeable to me. Just don’t overlook this point: we can’t create successful software through better behavior specifications. We need to accept that we don’t really know how to design software like the waterfall methodology said we’re supposed to. We need a methodology and supporting tools that work with and enable the creative process of the human mind.
Jester is not a code-verage replacement, its designed to be used in addition to traditional code coverage tools. Like you I also use Clover, and think its very handy.
As for not being able to create better software through better behaviour specifications, I agree 100% – it doesn’t matter how good the specification is, if its a specification of a bad design.