The Design-by-Contract methodology makes clear separation of responsibilities:
- a client has to fulfill a precondition of a supplier
- a supplier has to fulfill its postcondition as soon as the precondition is fulfilled
As a result of this policy
- if the precondition is violated, it is a fault of the client (the client is "guilty", it is a bug in the client's code)
- if the postcondition is violated, it is a fault in the supplier (the supplier is "guilty", it is a bug in the supplier's code)
That's why it is called "contract" - it is a contract/an agreement between two parties - the client and the supplier - to meet these conditions.
From the client's point of view, it has to fulfil the precondition, but then it can rely on the postcondition that is an obligation of the supplier. There is no need to recheck the output.
In real life it is up to the author(s) of the supplier code how to make sure the output is always correct as soon as the input is correct, be it debugging, testing, verification, code review or something else. In the environments that support DbC natively, it is possible to perform run-time monitoring of preconditions and postconditions during program execution. Contract violation immediately points to the party that is buggy.