Unit Testing vs Design by Contract
In order to determine correctness of the program three questions must be answered:
- What does routine expect?
- What does routine guarantee?
- What does routine maintain?
In second half of the book the concept of Unit Testing is explained. Writing tests can ensure to a first approximation previous three questions.
Let’s imagine if just only one of this concepts is practiced. For example, a Design by Contract?
For now I want to emphasize just two points:
- Bad customer experience. Assertions and invariants tends to be happen not in development environment but somewhere next in continuous delivery pipeline.
- From technical perspective refactoring is hardly possible. Getting feedback about changes made to the system tends to be happen not in development environment also.
On the contrary, I want to know about how changes affect system in the Work-In-Progress stage.
I think these both concepts - Unit Testing and DBC - should complement each other. Unit testing should be practiced and implemented in tests. Design by Contract should be practiced and implemented as a mental model. Something that engineer should always have in the background during his work.
- Design by Contract was developed by Bertrand Meyer in 1986 when he was working on Eiffel programming language. [return]