[Exceptional C++ Style] Re: Unit tests and assertions

[Jon Jagger]

Kevlin Henney wrote:

> In message <018a01c4f64b$1e6fccc0$0300000a at pc>, Terje Slettebø 
> <tslettebo at broadpark.no> writes
>
>>> From: "Kevlin Henney" <kevlin at curbralan.com>
>>
>>
>>> In addition, introducing such a DbC framework is generally a waste of
>>> effort. Although it is based on good intentions, it is mostly ritual
>>> rather than time well invested. A set of unit tests will be a much
>>> clearer guide to the contract and the interface. Wading through an NVI
>>> version of a contract is more than a little tedious, especially when 
>>> the
>>> notion of contract enforcement is based on assertions: all that
>>> infrastructure for something that isn't even compiled in.
>>
>>
>> Unless I misunderstand you, aren't unit tests and asserts rather
>> complementary to each other? The asserts checks
>> preconditions/postconditions/invariants, while you may use unit tests to
>> check that they indeed work, i.e. exercise the asserts.
>
>
> When a contract is phrased so that it does not describe what happens 
> when the normal terms of a contract are violated, the assumed 
> behaviour is undefined, ie the program may terminate, an exception may 
> be thrown, the called function need never terminate, everything may 
> continue as normal, etc. A contract phrased like this could be checked 
> (or ignored) quite legitimately through 'assert' (as in the <cassert> 
> macro). However, there is nothing for a test case to assert in such a 
> case.
>
> Where a contract also publishes the specific quality of failure for 
> transgression of some or all of its normal parts, because such 
> behaviours are published in terms of definite measurable outcomes, 
> they may be tested for.
>
> What example-based unit test cases allow you to do is present and 
> check the items specified in the contract associated with a measurable 
> outcome. In other words, specific normal outcomes in valid situations 
> and specified bad-news in unpleasant circumstances.
>
So, turning the discussion on its head a little, a natural question is 
when should a contract specify only the behaviour when the preconditions 
are met, and when should it also specify (to some degree) the behaviour 
when the preconditions are not met?
Failed preconditions are not "functional" but they can be "operational". 
For example, it would be a bad move to not test preconditions only to 
find that failed preconditions somehow opended a security hole....
Cheers
Jon