Although it would be good to have an Assert.ExpectedException that did
the try/catch for you in the code since this is a frequently recurring
pattern.
Assert.ExpectedException(typeof(SomeException), delegate {
x.DoSomethingThatThrows();
});
// Now we know that it threw so we can inspect the rest of the state of
the object.
// This is useful for verifying that finally blocks did the expected
cleanup
// so the object is still in a valid state. (All invariants preserved.)
Assert....
Jeff.
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED]
On Behalf Of Graeme Foster
Sent: Monday, October 23, 2006 1:27 AM
To: [email protected]
Subject: MbUnit Re: How to continue a test after ExpectedException
occurs
On 10/23/06, Findulias <[EMAIL PROTECTED]> wrote:
>
> Think I was too fast with my other posts here :-) The Try/cath was not
> intended to be used together with the ExpectedException but instead?
> And then the Assert.Fail is not redundant.
That's right. A try/catch is most useful to check the state of test
objects is correct in the event of an exception. With the
ExpectedException you don't get a chance to test the objects after the
exception.
Usually it is enough to use the ExpectedException attribute to make sure
the exception is thrown in the correct circumstances.
Cheers,
G.
--
Graeme Foster
Aston 7 Product Manager
Aston Broadcast Systems Ltd.
http://www.aston.tv
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MbUnit.User" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/MbUnitUser
-~----------~----~----~----~------~----~------~--~---
