This is the second part of a series of blogpost on unit testing. Find the first part here.
In the first part we’ve introduced the MS Test framework, and I realise now that I’ve left out a few bits and pieces, so first off let me try to make amends.
Initialize and Cleanup
Many times when running a test you’ll want to set up some conditions under which the test will run. After completion you’ll want to clean up these artifacts. Similarly to NUnit, where you’ll find attributes as [Setup] and [TearDown], MS Test has some attributes you can use to accomplish this.
To set up state before every test method in a test class, you can decorate a method with the [TestInitialize] attribute. Similarly, to clean up you can use the [TestCleanup] attribute.
For example, suppose you are testing some xml parsing routines. If you are testing agains some sample xml fragment, and it’s the same fragment for all your test methods in a class, you can set the fragment using the [TestInitialize] attribute:
private MyDataContext db;
[TestInitialize()]
private void TestInit()
{
db = new MyDataContext(
ConfigurationManager.ConnectionStrings["TestDatabase"].ConnectionString);
db.Connection.Open();
}
Similarly, you can use the [TestCleanup()] attribute to dispose of any state.
[TestCleanup()]
private void WrapUp()
{
db.Dispose();
db = null;
}
Note: you only use a db connection setup like this when testing data access routines. For any other routines you do not really want the tests to hit the database.
So that’s pretty convenient: you don’t have to add the initialization code in the methods themselves. However, the opening and closing of the database will occur as many times as there are test methods in your test class.
You can use the [ClassInitialize] and [ClassCleanup] attributes for state changes that will execute only once for all test methods within a test class. However, for methods to use these attributes they must be static, which means that you can not use it to set properties on the instance of the test class.
Testing for exceptions
A lot of times I’ve seen developers using a try/catch block to test for exceptions. Joel for example has posted this little code snippet:
[TestMethod]
public void TestZipCodeNotNumericThrowsArgumentException()
{
TransactionRequestInfo req = new TransactionRequestInfo();
string testValue = "034JB";
try
{
req.Zip = testValue;
Assert.Fail("Exception not thrown.");
}
catch (ArgumentException aex)
{
Assert.IsTrue(true, "Exception Thrown Properly");
}
}
You can see what he’s trying to do, and I’ve seen many a test use this approach. There is a better way: let’s rewrite this using the appropriate ExpectedException attribute:
[TestMethod]
[ExpectedException(typeof(ArgumentException))]
public void TestZipCodeNotNumericThrowsArgumentException()
{
TransactionRequestInfo req = new TransactionRequestInfo();
string testValue = "034JB";
req.Zip = testValue;
}
You can see it pays to investigate the full capabilities of the testing framework. Note that one would probably want to use a more specific exception than ArgumentException (InvalidZipcodeException?), but that’s for another post and another day.
On cleanup and debugging
When dealing with databases, you might on occasion use a method with the TestInitialize attribute to verify preconditions in the database, and similar you have a cleanup routine to remove any artifacts. What happend to me on more than one occasion when starting with unit tests is that I would run tests under debugging, and when an expection occurred I would stop the debugging session. This however would prevent execution of any cleanup routine, and the state would not be properly reset before the following test run. Be sure to continue debugging to allow your cleanup code to execute!
Keyboard Shortcuts
To wrap up the specifics of the MS Test frameworks, here’s a list of keyboard shortcuts to run your tests. The running of tests through the test windows is a bit cumbersome to navigate, so these keyboard combinations will come in handy:
CTRL + R, then press T
This runs the test(s) in the current scope. That is, it runs the current test method, all the tests in the current test class, or all the tests in the namespace, respectively.
CTRL + R, then press CTRL + T
This also runs the test(s) in the current scope, but under debugging.
CTRL + R, then press C
This runs all the tests in the current test class.
CTRL + R, then press A
This runs all the tests in the solution.
Resources
MSDN documentation on Unit Testing
Write Maintainable Unit Tests That Will Save You Time And Tears (MSDN article by Roy Osherove)
If you’re looking for a good book on unit testing, I can recommend Pragmatic Unit Testing in C# with NUnit , by Andrew Hunt and David Thomas. The authors use nUnit as the test framework, but the methods and practices apply regardless of what framework you use.
Roy Osherove shares his thoughts on unit testing and his upcoming book on The Art of Unit Testing/
) , but it was basically the same session that Platt has been delivering for a number of years now, most recently in TechEd Barcelona in 2007, and I was a bit surprised when I found out this talk was now promoted to keynote for the DevDays. Must have been a slow day at the office for original content or new announcements….
