Design by contract
Some parts of the software we are working on are not meant to be called directly by users, but instead by other parts of the code. Such is the case when we divide the responsibilities of the application into different components or layers, and we have to think about the interaction between them.
We have to encapsulate some functionality behind each component and expose an interface to clients who are going to use that functionality, namely, an Application Programming Interface (API). The functions, classes, or methods we write for that component have a particular way of working under certain considerations that, if they are not met, will make our code crash. Conversely, clients calling that code expect a particular response, and any failure of our function to provide this would represent a defect.
That is to say that if, for example, we have a function that is expected to work with a series of parameters of type integers, and some other function invokes...
