In my last post I talked about migrating from NUnit to MSTest and mentioned that there were some Assert methods that NUnit provided which did not have corresponding methods in MSTest. For reference, those unavailable Asserts are: Assert.IsNaN Assert.IsEmpty Assert.IsNotEmpty Assert.Greater Assert.GreaterOrEqual Assert.Less Assert.LessOrEqual Assert.IsAssignableFrom Assert.IsNotAssignableFrom CollectionAssert.IsEmpty CollectionAssert.IsNotEmpty StringAssert.AreEqualIgnori... StringAssert.IsMatch...
I have been writing a lot of unit tests over the past month using the Microsoft Test (MSTest) unit testing framework that is now part of Visual Studio 2008 Professional Edition (and higher SKUs). Currently I have about 223 unit tests covering 39 classes (about 18K lines of code, 325 methods and 176 properties) with a code coverage percent of 97%. The classes that I’m testing previously had NUnit tests (although not as many as I currently have) and used NCover and NCover Explorer for my code coverage...
When writing unit tests that cover methods that can throw known exceptions, you generally want to make sure that your tests actually test the conditions that can cause the exception and that you do, in fact, throw the correct exception. Most unit test frameworks, including MSTest and NUnit, use an ExpectedExceptionAttribute to decorate the test method. There are actually several problems with using ExpectedExceptions that make it more difficult to write good unit tests. The first problem is the fact...
I have been writing a lot of unit tests lately using Microsoft Test. This included converting a bunch of old NUnit tests to the MS Test format, which was relatively painless. While examining the code coverage results (after all, what good are unit tests if you don’t know what portions of the code are being tested and not tested), I have noticed that the results sometimes lie. For example, I have a class that contains some extension methods for manipulating enums. One of those methods takes an enum...