Recently I wrote about the necessity in TDD of specifying both sides of a behavioral boundary, and its epsilon. This is important because we want a complete, detailed record of the critical business rules and other values in the system.
But there is another reason that this is important. It has to do with the notion of “a specification.”
Why do we want a specification, as developers? Simply put, it is to help us to write the correct code. The best specification, therefore, would ensure we write the correct code. It says “If you make a mistake, I’ll tell you right away.”
If, as I mentioned in the previous example, we wrote a test that said, “A value of 101 will be reduced to 89.1.” that test would pass if the code always applied the 10% discount, no matter what the value is. That would be the wrong code, but the test would pass. It would fail to tell us we had made a mistake.
If the boundary is fully specified, however, we will have to put a conditional into the code, and if the epsilon is specified, then the conditional will have to be implemented with the right level of precision.
That’s what good specifications do and only TDD makes them executable/automated. They become enormously valuable to developers.
-AMAZONPOLLY-ONLYAUDIO-START-
This is Scott Bain. Visit us at www.netobjectives.com.
-AMAZONPOLLY-ONLYAUDIO-END-