Often a given behavior will change due to a certain condition: sometimes the system will behave one way, sometimes another. We call this kind of behavioral change a “boundary” and it should be specified as such in TDD.
For example, let’s say there is a business rule that dictates how a passed-in value should be handled. If the value is greater than 100, we decrease it by 10%; a kind of quantity discount.
Those new to TDD might simply specify that a value of 101 should be decreased by the system to 89.1. But this is not enough. Boundaries have two sides, because two behaviors are implied by this rule: to apply the discount, and not to. Therefore, we need two tests. One would show the discount being applied, and the other would show the value was unchanged.
But we also need to show the degree of change in the value needed to trigger the behavior. Is it 1 over 100 (as our test says)? Is it 0.01 (pennies, if this is money)? Is it smaller? Larger? A test should specify this “epsilon” as well.
Creating the the test suite as a “detailed executable specification” helps us to ensure that all important business information is captured.
But there is another reason why boundaries must be captured in this way. Stay tuned.
This is Scott Bain. Visit us at www.netobjectives.com.