design by contract versus doctest

[Yermat]

aku wrote:
> There seems to be a contradictive approach in 
> these two things. Example: In the doctest documentation
> (http://www.python.org/doc/current/lib/module-doctest.html)
> a required precondition (i.e. n is an integer and >= 0)
> is verified in the function itself:
> 
> if not n >= 0:
>         raise ValueError("n must be >= 0")
> 
> But in "design by contract" this responsibility is squarely 
> on the shoulders  of the caller, and is *not* checked in
> the function.
> 
> I'm confused as to what the "best" approach is.
> 
> Isn't it so, that by applying DBC, a lot of unittests can be
> made redundant?
> 
> shan.

I disagree with you !
Both are needed and not contradictory...

In design by contract, you assume that caller do not call you with 
stupid argument. So you can see this precondition as something sure or 
as something to check.
In the language that use the most Design by Contract, ie Eiffel, by 
default it check those condition on all call and give you something like 
and assert Error. (see 
http://www.python.org/doc/essays/metaclasses/Eiffel.py for something 
similar in python). But when you have finish to write your application 
you can compile it without those check because you are sure nobody will 
do false check !
Like in python if you optimize byte code (option -O), it delete all 
assertions.

Hence there is no contradiction.
And to improve your code, you can (must?) do unittest with, for example, 
doctest.

Yermat