Unit Tests and DbC assertions are complementary, not exclusive. I always 
do both.

I tend to put the "post condition" assertions in the Unit Tests and 
invariant and pre-condition assertions in the code.

Why?

1) The pre-condition assertions are "tests of the tests". Test's are code
    too, therefore have bugs.

2) Post-conditions are effectively the asserts found in the unit test. ie.
    If you have strong test coverage, don't bother with post-condition
    asserts, refactor them into the unit test code.

2) Client code using my code has bugs and the precondition asserts catch a
    lot of them very rapidly and at the right point. A the client code Unit
    test  postcondition assert says the client (or maybe the lower layer)
    code did vaguely the wrong thing  somewhere someplace sometime. A
    Precondition assert says the client code violated a pre-condition
    RIGHT HERE.

3) Invariant code are Object Sanity Checks. Stroustrup (author of C++)
   recommends quite sanely that you should only spin a class if and only if
   you have an invariant to protect. Invariant checking method is a handy
   way of checking at run time that your class is doing what it was
   designed to do.

4) I always throw vanilla Exceptions on assertion failure. It meshes 
nicely with the stacktrace mechanism of Ruby, but so far I can't think of 
any good reason to create a new exception class for them.



On Mon, 6 Mar 2006, chiaro scuro wrote:

> I would get my assertions to raise exceptions too.  They are just a
> specific kind of exception, related to the domain of inputs and
> outputs, different from exceptions generated from something that goes
> wrong in the middle.
>
> What do other people think about the relationship between assertions
> and exceptions?
>
> On 3/6/06, Pat Maddox <pergesu / gmail.com> wrote:
>>> tests alone however are never exhaustive and cannot prove correctness.
>>> assertions can catch some types of 'wrongness'.
>>
>> Isn't that what exceptions are for?
>>
>> def foo(a)
>>   raise 'Argument can not be negative' if a < 0
>>
>>   b = something_that_should_always_be_positive
>>
>>   raise 'Something strange happened and b was negative' if b < 0
>>   b
>> end
>
> --
> -- Chiaroscuro --
> Liquid Development: http://feeds.feedburner.com/LiquidDevelopment
>



John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter / tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.