Design by Contract

A little confession about one of my most recent software projects: it has a lot of unit tests in it. But for every test assertion, there are more than three assertions in the code itself.

These have proven invaluable for documenting my assumptions about how the code is put together. While unit tests show that each method or class works as expected in isolation, these assertions are about ensuring that the boundaries respect the assumptions that are made within the methods – that is, they act as a form of integration test.

The assertions I've written mainly fall into three categories – testing that expectations are met when the method is entered, that its results are what I expected before it was returned, and that certain transformations done during the method yield results conforming to particular conditions. In developer builds, whenever one of these assumptions is not met, the app crashes at the failing assertion. I can then decide whether the method...