Here's what I do :
In math, I was always taught to specialize until the general case becomes apparent. This is what TDD teaches us. Each JUnit test becomes a special case. It's easier to grok the special cases and it's easier to do the required setup for a special case. However it's often hard to see the general rule from a collection of special cases and that's where DbC comes in. Agitator is good at finding and enforcing the general rule - it will even check that the general rule holds as each individual JUnit case runs.
Here's an example, I wrote a custom LayoutManager recently and I started in the usual way. What happens if there are no components? What happens if there is one component? Two? and so on. At the end, I started to write a test for the general case - but the resulting test was almost a duplicate of the code in my actual LayoutManager. Instead, I switched to the Agitator and added a set of invariants and got the best of both worlds.
On several occasions in the past, I have found myself discussing testing with another developer and we were just completely unable to understand each other's point because we had different world views. He was seeing from a DbC point of view while I was seeing from a TDD point of view. In his view, TDD could never work because it could never cover all the cases. In my view, it was too hard to come up with invariants that were strong enough to be both useful and universally true. As is often the case, we were equally right and wrong. Both are useful and the combination of the two is very powerful - and that's what I do.
Posted by Kevin Lawrence at December 9, 2004 01:20 PM
TrackBack URL for this entry: