From: Jim Weirich <jweirich@...>
Date: 2003-01-07T10:46:55+09:00
Subject: Re: Interfaces in Ruby (attempted summary)

On Mon, 2003-01-06 at 15:02, Robert wrote:

> > Good Summary ...
> 
> thanks!

:-)

> > I've found that when doing Test-Driven-Design, the unit test cases
> > provide much the same information as an explicit interface (and
> > contract).  Perhaps the documentation issue with interfaces can be
> > addressed in the test case.
> 
> or even more than this: maybe someone finds a way to integrate these.
> wouldn't it be nice if the part of the test that verifies the contract could
> be reused in production code since it is essentially the same?  or would
> that bring in too much interference between test and the "real" code?

Are you advocating running the unit test in the runtime code?  I'm not
sure this makes sense.  For one thing, the unit test may modify the
object in the course of testing it (for example, a unit test might push
an item onto a stack to test the push method).

Although there is significant overlap between DbC and Unit Tests (UT),
there are still some basic differences.  After I wrote EiffelUnit, I
published some thoughts on DbC and Unit Testing (I put the notes at
http://w3.one.net/~jweirich/talks/dbc-and-unittests.html).  

In summary ...

(1) DbC assertions check every call, but only when they are enabled.
    UT only check during the unit test run.

(2) It is difficult to test for precondition correctness in UT.

(3) Both UT and DbC test postconditions.  DbC expresses the
    postcondition in general terms that must always be true.  UT are
    written against explicit and concrete situations designed in 
    the unit test.

-- 
-- Jim Weirich     jweirich@one.net    http://w3.one.net/~jweirich
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)