Listen to this post
Most requirements are statements of desired behavior. But there can be implications behind these requirements concerning behavior that is not desired.
For example, we might test-drive a value object that represents some domain information, and the requirement for it might include that the object must be “immutable.” The implication would be that the object has no mutator methods allowing the values contained to be altered.
How can we write a test that specifies that a method does not exist? Test code that tried to access a non-existent method would obviously not compile.
You might think, “Add a set method that throws an exception if called.” But throwing an exception is not the requirement.
You might be tempted to use reflection. That will make your test too slow. And what will you look for? A method called “Set”? “Change”? “Alter”? “Put”? The list is awfully long.
TDD is about specification. Specifications have a two-part rule about this:
- Specification must be complete. No behavior exists that is not in the spec.
- Given #1, anything not in the spec is not in the system.
Thus, the lack of a test that specified that there is a mutator method means there isn’t one. This is assured if we follow the process.