Unit tests and assertions (was: [Exceptional C++ Style] Item 18 - Virtuality)

[Kevlin Henney]

In message <opskcl4t1mv17jmk at smtp.ntlworld.com>, Ric Parkin 
<ric.parkin at ntlworld.com> writes
>
>> 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.
>
>I don't think it's quite so one-or-the-other - my DBC and Test 
>libraries  integerate to the extent that the DBC checks will throw 
>exceptions when  being tested, and the tests check that said exceptions 
>are in fact thrown.

This moves what I categorised as (1.ii) temporarily, in the world of the 
test, into 2.

>So even though a precondition failure results in UB, the tests can 
>actually tie this down and check for it.

However, I am not actually sure what this buys you. My first concern is 
that the fact that a piece of code under test has some feature of it 
that is aware of the fact that it is being tested. My second concern is 
that...

>The advantage of this is that changing preconditions have the usual 
>safety  net of the test, even though in release builds the checks 
>aren't there.

I don't see why testing for some behaviour that is not part of the 
deliverable is going to be useful. All you have proved is that some 
behaviour that is only present during testing, and has no effect on the 
delivered behaviour, is present and correct during testing. This is 
circular, and cutting it out would probably make the tests briefer and 
more accurate in their reflection on what is being tested!

>> Preconditions fall into two broad groups:
>>
>> (1) Preconditions with no associated penalty terms for violation, ie 
>>undefined behaviour. These cannot be tested for in unit test 
>>cases.They    test the correctness of the caller rather than the 
>>called code, so there   is nothing to test at this level.
>> (2) Preconditions associated with some form of well-defined penalty, 
>>eg   an exception. With the exception of a contract that leads to 
>>process   death, these can be tested for using unit tests.
>
>My point is that these two cases are not always seperated - the beauty 
>of  UB is that you can define it if you want to your own ends.

So far they seem to be. I suggested that one can use UB to one's own 
ends in my posting, but this particular end seems to be a dead end.

Kevlin
-- 
____________________________________________________________

   Kevlin Henney                   phone:  +44 117 942 2990
   mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
   http://www.curbralan.com        fax:    +44 870 052 2289
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________