Imagine a system written in Eiffel with perfect use of ‘design by contract’ so that every function is surrounded by preconditions and postconditions. All arguments are checked, and all return values are checked.
Imagine this is true for every pathway through the system. Imagine that the system is entirely closed within ‘design by contract’. Every output is checked. Every input is checked.
It should be obvious that in a closed system like this the inputs to each function come from the outputs of other functions. Thus every potential input has already been checked before it arrives.
Every information flow is therefore tested twice. Once as it leaves the producing function, and again as it enters as a parameter to the function being called. This begs the question: why should each information flow require two tests?
Indeed, if we trust the postconditions of each function, then we know that all the outputs will be correct. Doesn’t this make the preconditions redundant? Or, if we trust all the preconditions, doesn’t this make the post conditions redundant?
Think of the act of calling a function as information flowing through a pipe. With both pre- and post- conditions we have tests and both ends of that pipe. Each information flow is tested twice.
By removing either the preconditions or the postconditions we reduce each information flow to have just one test. But one test is sufficient for an information flow.
Now let’s move that test into the middle of the pipe. It is no longer a precondition or a post condition. It is simply a test of the data within the pipe. Let’s call that kind of test, a unit test.
Now remember our system was closed within design by contract. By replacing the pre- and post-conditions with unit tests we have not reduced the testing on any of the information flow. So the system is still closed. All information flows are tested.
Defensive programming — checking each argument at the start of a function — is the same as writing preconditions. In a system closed under test defensive programming is redundant.
Static typing is also a kind of precondition test. Or rather it is test that ensures the data within the information flows is consistent. Again, this is redundant in a system that is closed under test.
This is an academic thought experiment. Creating a system that is completely closed under test is probably impractical.
On the other hand, after 20 years of using TDD I have definitely found that I rely much less on defensive programming and static typing than I used to.
