Ned Konz wrote:

>  On Sunday 11 May 2003 10:57 am, Stephane Ducasse
wrote:
>  
>  > why what I was syaing was wrong? If I do should:
[] raise: MyError
>  > this is not working?
>  
>  I thought that Anthony wanted to be more specific. 

Ned is correct. 

I'm trying to write an sUnit test which checks to make
sure a specific error has been thrown. Rather than
passing the test simply because just any error got
thrown. How do I know the *expected* error occurred
rather than an unexpected one? Especially, when the
expected error does not exist as a special pre-defined
class in the image. e.g.- ZeroDivide is a special
pre-defined Error while others resulting aren't. These
others kinds are some kind of Error instances, I
assume. This is the sort I'm looking for.

>He can't define
>  MyError if he's looking for a pre-existing Error
that's already being
>  raised by another (pre-written) class. So he has to
look at both the
>  class of the error (Error) and its description ("is
not in the
>  collection").

>  Certainly if you have a predictable error class
that actually *means*
>  something (as opposed to the widespread use of
Error for all kinds of
>  things in the image), you should look for the class
instead.

I didn't see an Error defined for this in the system
for the expected Error resulting from the detect
message not finding any even numbers.

While I did figure out how to insert a description I'm
not sure how one is suppose to prep an expected
non-predictable Error class instance before passing it
in sUnit's shouldn't message? In any event this is
what I tried after reading Stephane's first post (this
doesn't detect the error properly either, by the way):


AnErrorTest(TestCase)>>testForError

notFoundError := Error new.
notFoundError messageText: 'Object is not in the
collection.'.
self should: [#(1 3 5 9)
																						detect: [:n | n even].]
							raise: notFoundError
							description: 'Should throw error if no even
numbers are detected.'.

The result was an exception ("Object is not in the
collection") was thrown despite the fact that an error
occurred.	The error message text was copied directly
from the Array method ("errorNotFound:") which
signaled the error.	 

This was worse than before since the example in my
previous message, which passed in the Error class with
shouldn't, while not specific at least caught the
error.
			
> On Sunday, May 11, 2003, at 07:40 PM, Ned Konz
wrote:
<snip>
> > I just posted a CS that lets you also test the
exception
> > description for a substring.

Thank you very much. I'll file it in and give it a
try.

Take care,

Anthony

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com