From: Matt Armstrong <matt@...>
Date: 2003-02-06T11:59:24+09:00
Subject: Re: Return values from assertions

<nathaniel@NOSPAMtalbott.ws> writes:

> Hmmm... after seeing that, I'm leaning towards leaving the return
> value to #assert_raises. The first way is just too much work, and
> the second way doesn't give me enough power.

Agreed.  The first way doesn't immediately convey the intent of the
test either -- i.e. that we're primarily checking for exception stuff.

>> > 3) Code examples showing the use of return values from other
>> > assertions.
>> 
>> I don't know if Test::Unit has the equivalent of RUnit's
>> assert_no_exception, but I have used it this way:
>> 
>>     h = RMail::Header.new
>>     # This time is out of the range that can be represented by a
>>     # Time object.
>>     h.add_raw("Date: Sun, 14 Jun 2065 05:51:55 +0200")
>>     t = assert_no_exception {
>>       h.date
>>     }
>>     assert_nil(t)
>
> I don't really understand what you're testing here...

User error here.  The assert_nil is clearly meaningless and works by
accident.

I've often wondered how useful assert_no_exception actually is, given
that the framework reports uncaught exceptions anyway.


> What I'm thinking at the moment is:
>
> 1) Leave in the return value from #assert_raises.
> 2) Remove the return value from #assert_match.
> 3) In general, avoid returning (documented) values from assertions.
>
> To clarify #3, I don't plan on returning nil from all the
> assertions, but I do plan on not explicitly returning something
> useful from them, and saying that if you depend on something that is
> returned as a side effect, too bad for you if it changes.

Given that I've only ever meaningfully used the return value of
assert_raises, that sounds good to me.  #3 is not my style (I'd just
return nil everywhere) but it is hard to come up with any real reason
to go one way or the other.