[Python-ideas] Pre-conditions and post-conditions

[Steven D'Aprano]

On Mon, Aug 27, 2018 at 11:01:21AM -0400, Wes Turner wrote:
> Runtime checks: data validation & code validation
> Compile-time checks: code validation
> 
> What sort of data validation is appropriate for assert statements or
> contacts that may be skipped due to trading performance for more risk
> ('optimized out')?

That depends on what you mean by "data validation".

Testing for bad input, or testing for predictable error states such as 
I/O errors, missing files, permission errors, server down etc is 
not appropriate for assertions (which includes contracts).

The rule I use is that assertions are for:

(1) testing your program state, which is under your control; and

(2) communicating the intention of your program as executable 
    code rather than comments.

The ultimate aim of contracts and assertions is to eventually disable 
them when the program is bug-free.

The Eiffel docs say:

    It should be clear from the preceding discussion that contracts
    are not a mechanism to test for special conditions, for example
    erroneous user input. For that purpose, the usual control
    structures [...] are available [...] An assertion is instead a 
    correctness condition governing the relationship between two 
    software modules (not a software module and a human, or a
    software module and an external device). ... Bluntly:

    Rule -- Assertion Violation: A run-time assertion violation is
    the manifestation of a bug.

https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions

For detecting *external* error states (anything to do with data that 
comes from outside your program, like user input) you can never let your 
guard down and never disable the test, because servers can always go 
down, users can always give you bad data, files can always be corrupt. 
It is unsafe to disable these tests and so these should not be 
assertions.

For a library function intended to be called by third-parties, the 
function arguments aren't under the control of the library author so 
should not be tested with assertions. But for an application where the 
author controls those function arguments, they are under the author's 
control and may be assertions or contracts.

Design By Contract is partly a methodology and partly a set of syntax. 
Its a way of thinking about the design of your program. In practice, you 
don't have to buy 100% into DBC to get some benefit for it. A study done 
a few years back looked at 21 large projects in Eiffel, JML (Java) and 
Code Contracts for C# and found that 33% of the classes used contracts.

http://se.ethz.ch/~meyer/publications/methodology/contract_analysis.pdf

Like unit testing, you don't need 100% coverage to get benefit. 10% is 
better than nothing, and 20% is better than 10%.

I wrote more about assertions here:

https://import-that.dreamwidth.org/676.html


-- 
Steve