From: "Volkmann, Mark" Date: 2002-10-05T03:20:02+09:00 Subject: Re: assertions in Ruby This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26BD2.8C81B490 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Jason Voegele [mailto:jason@jvoegele.com] > Sent: Friday, October 04, 2002 9:30 AM > To: ruby-talk@ruby-lang.org > Subject: Re: assertions in Ruby > > > Volkmann, Mark wrote: > > Yes, I'm aware of RubyUnit. I love it and use it > extensively! However, > > I think there is a place for assertions too. Assertions > provide useful > > documentation inside the code as opposed to be being in a > separate file > > as I believe most unit tests are implemented. My examples > demonstrated > > another potential use of assertions which is to provide a > weak form of > > type checking ... which of course has been a controversial > issue on the > > mailing list in the past few weeks. > > http://www.pragmaticprogrammer.com/ruby/downloads/dbc.html > > It's an implementation of Design By Contract for Ruby put together (I > believe) by Andy Hunt. And although it should be viewed mostly as a > prototype, it is directly usable and may inspire you to grow it into > something greater. DbC looks interesting, but it's also much more involved than the Java Assertions API which is what I used as a model. I have a basic assert method that accepts a boolean condition (similar to the check method in DbC). I also have a few variations of the assert method for common kinds of assertions like verifying that an object responds to a set of messages or is a kind of one of a set of classes. These assertions can be placed wherever they are appropriate. DbC has three constructs that perform assertions at different points in a method ... pre for the beginning, post for the end and check for places in between. There are also methods to determine the value of an expression before the current method started (old) and to determine that a condition is met at the end of executing every method in a class (invariant). All of this is interesting, but also may be overkill. Obviously this is a matter of opinion. Sometimes simpler is better and this feels like one of those times to me. Another concern is that the date on the DbC documentation is August 2000, the software is still marked as version 0.1 and the status on the web page is "Alpha (i.e., use at your own risk)". *********************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. ************************************************************************************ ------_=_NextPart_001_01C26BD2.8C81B490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: assertions in Ruby

> -----Original Message-----
> From: Jason Voegele [mailto:jason@jvoegele.com]
> Sent: Friday, October 04, 2002 9:30 AM
> To: ruby-talk@ruby-lang.org
> Subject: Re: assertions in Ruby
>
>
> Volkmann, Mark wrote:
> > Yes, I'm aware of RubyUnit.  I love it an= d use it
> extensively!  However,
> > I think there is a place for assertions too.&n= bsp; Assertions
> provide useful
> > documentation inside the code as opposed to be= being in a
> separate file
> > as I believe most unit tests are implemented.&= nbsp; My examples
> demonstrated
> > another potential use of assertions which is t= o provide a
> weak form of
> > type checking ... which of course has been a c= ontroversial
> issue on the
> > mailing list in the past few weeks.
>
> http://www.pragmaticprogrammer.com/ru= by/downloads/dbc.html
>
> It's an implementation of Design By Contract for Ru= by put together (I
> believe) by Andy Hunt.  And although it should= be viewed mostly as a
> prototype, it is directly usable and may inspire yo= u to grow it into
> something greater.

DbC looks interesting, but it's also much more involved t= han the Java Assertions API which is what I used as a model.

I have a basic assert method that accepts a boolean condi= tion (similar to the check method in DbC).  I also have a few variatio= ns of the assert method for common kinds of assertions like verifying that = an object responds to a set of messages or is a kind of one of a set of cla= sses.  These assertions can be placed wherever they are appropriate.

DbC has three constructs that perform assertions at diffe= rent points in a method ... pre for the beginning, post for the end and che= ck for places in between.  There are also methods to determine the val= ue of an expression before the current method started (old) and to determin= e that a condition is met at the end of executing every method in a class (= invariant).  All of this is interesting, but also may be overkill.&nbs= p; Obviously this is a matter of opinion.  Sometimes simpler is better= and this feels like one of those times to me.

Another concern is that the date on the DbC documentation= is August 2000, the software is still marked as version 0.1 and the status= on the web page is "Alpha (i.e., use at your own risk)".<= /P>

***************************************************************************= ********
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
***************************************************************************= *********
 ------_=_NextPart_001_01C26BD2.8C81B490--