see inline...

> I know I should have written my tests first, but I didn't, so now I'm
> trying to do them after the fact.  I'm running into a few style
> questions, though, not being used to the Test::Unit style of testing:
> 
> 1) I have several test cases that do multiple assert_* calls.  Is that
>    a Good Thing, a Bad Thing, or not something that's even worth
>    worrying about?  Usually it's things like "Was the file created?
>    Does it contain data of the right format?  Is the data correct?"
> 
>    In one case, however, the test case is "run a command remotely that
>    logs to yet another remote database, and verify the command was
>    run, output was generated, logged to the right database with the
>    right timestamp, from the right machine, etc., etc., etc."
>

It seems to me like you are trying to do too much in a single test.  
I would have tests for the item that you are testing remotely.  Since 
those test would actually be locally, you can then break them down 
into small simple tests, and then when that is tested you only have 
to simulate your remote procedure call in a test.
 
> 2) How do people generally feel about interactivity in test cases?  I
>    have a method that should send email to a random address.  Since
>    I'd like everybody on my team to be able to run my tests, I can't
>    use a specific address, as that address might not (probably won't)
>    exist on their machine, and depending on which OS they're running,
>    the mail spool dirs will be in a different location.
> 

This too could be broken down.  I have test that tests 
sending/reading of an email class.  That test does in fact use a mail 
server.  Once you have done that and you know that your email class 
works, it looks like you need a test that tests the random email 
address to send to.  If you actually need to test sending an email, 
you can then use the class interface to simulate the sending of an 
email (Google mock object).

>    My idea is to have the test ask for the address by stdin, and also
>    ask the user to verify the contents manually.  The user's response
>    will determine if the test passes or fails.

In general I think it is a bad idea to require input.  One of the key 
things to automated unit tests, is that they are, well... automated.  
They just run and tell you success or failure.  For me that's why I 
like them.

> 
> Other than that, I'm enjoying Test::Unit quite a lot.
>

cool.


Walt
*****************************************************
Walter Szewelanczyk
IS Director
M.W. Sewall & CO.        email : walter / mwsewall.com     
259 Front St.            Phone : (207) 442-7994 x 128
Bath, ME 04530           Fax   : (207) 443-6284
*****************************************************