[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: assertions in Ruby
From:       Alan Chen <alan () digikata ! com>
Date:       2002-10-04 18:36:11
[Download RAW message or body]

On Sat, Oct 05, 2002 at 03:07:53AM +0900, Volkmann, Mark wrote:
> 
> > -----Original Message-----
> > From: Alan Chen [mailto:alan@digikata.com]
> > Sent: Friday, October 04, 2002 11:37 AM
> > To: ruby-talk@ruby-lang.org
> > Subject: Re: assertions in Ruby
> >
> > On Fri, Oct 04, 2002 at 10:43:46PM +0900, Volkmann, Mark wrote:
> > >
> > > Is anyone aware of a Ruby module that adds support for
> > assertions such as what
> > > is supported in Java 1.4?  I wrote such a thing yesterday
> > and am considering
> > > releasing it if I'm not duplicating what someone else has
> > already done.
> > > I've included some examples below showing how mine is used.
> >
> > I have an unreleased, partailly completed module which include the
> > Test::Unit asserts when $DEBUG is set and do nothing otherwise. It
> > looks almost the same as yours.  The only suggestion I have is maybe
> > working it in with the Ruby::Unit or Test::Unit frameworks.
> I'm not quite convinced that assertions should be integrated with a unit
> testing framework. They seem fundamentally different to me.
> With assertions enabled, an application generally stops as soon as one fails. 
> Results are not collected into a report since only one failure is reported. 
> Assertions go in the code and remain there for documentation purposes.
> With unit tests, tests continue even if one fails.  Results are collected into
> a report.  Unit tests go in a separate class written exclusively for testing
> purposes.
> What kinds of things do you envision that an assertion framework borrow from a
> unit testing framework?

Sorry, I didn't mean to imply that unit testing and assertions should
be strongly tied together.  Test::Unit for example provides a wide
range of asserts already. The Test::Unit assert code itself is a
fairly orthogonal module, and, as far as I know, has no other
dependencies on other parts of the unit test framework.  So.. I just
did something like the following:

if $DEBUG
	module Myasserts
		require 'test/unit/assertions'
		include Test::Unit::Assertions
	end
else
	# all empty assert methods
	module Myasserts
		def flunk(msg);end
		def assert(expr,msg);end
		# other assertions omitted...                
	end
end

Now instead of Myasserts, an integrated module might be named
Test::Assertions.  The main reason to separate into its own module is
that you always want the asserts to fire in a unit test, but not
always during an application run.  I don't really care if its
$DEBUG that controls it or some other flag. $DEBUG was just convenient
in my case.

-- 
Alan Chen
Digikata LLC
http://digikata.com

[prev in list] [next in list] [prev in thread] [next in thread]