[mristin]

P.S. I think the important bit is not to be religious about contracts and tests. Sometimes it's easy to write the contracts and have the function automatically tested, sometimes unit tests are clearer.

I tend to limit myself to simple contracts and do table tests for the complex cases to reap the benefits of the both approaches.

[HelloNurse]

If a software module maybe has tests and maybe has contracts, I "reap the benefit" of not being able to rely on either.

Do you have in mind some technique to turn contracts into tests or tests into contracts automatically, in order to close the gaps in quality control?

[mristin]

Sorry, I did not express myself clearly. For certain functions you can express all the properties in contracts and have them automatically tested.

For other functions, you write some obvious contracts (so that those are also tested in integration tests or end-to-end tests), but since writing all the contracts would be too tedious or unmaintainable, you test these functions additionally using, say, table-driven tests where you specifically test with data points for which you could not write the preconditions or you check the post-conditions manually given the input data. For example, sometimes is easier to generate the input, manually inspect the results and write the expected results in the test table.

> [...] turn contracts into tests [...]

icontract-hypothesis allows you to ghostwrite Hypothesis strategies which you can further refine yourself.