"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.