"Some Message" is actualy the assert message if the expection is not thrown. For example:
[ExpectedException(typeof(InvalidOperationException),"Expected InvalidOperationException to be thrown")]
Jamie wrote:
<blockquote>
"Some Message" is actualy the assert message if the expection is not thrown. For example:
[ExpectedException(typeof(InvalidOperationException),"Expected InvalidOperationException to be thrown")]
</blockquote>
------------------
Although this may be true for Team System, isn't the case with NUnit.
> they just want to use the simplest thing that works
I would prefer the QA tested for the correct exception, rather than the simplest thing that worked.
Regarding testing the message - you would start having issues with localization if that was the case. I would like the ability to run some sort of RegEx over the exception message.
David:
The QA is not the one doing Test Driven Development- that's why it's called "Developer Testing".
However, I agree about the localization issues that can arise. There are better ways to check for the message ina multi localized way. My issue was that is the quality tools in VSTS want to be a NUnit killer, they should start out with the basic NUnit features and make them work first.
Another oversight in TS Unit testing that may cause some hideous bugs is that the Assert class does not override the static Object Equals() method. A developer may write:
Assert.Equals(expected, actual);
In a unit test expecting that an assertion would be raised and instead it does nothing since Object.Assert() just returns true or false and allowing the unit test to pass.
While this code would compile for TS, NUnit & MbUnit, both NUnit and MbUnit override the Assert.Equals() method of object and correctly make your unit test fail with "Assert.Equals should not be used for Assertions"
Todd, thanks for pointing out the oversight. I'll file a bug for us to consider matching teh behavior of NUnit and MbUnit for Assert.Equals.