My latest MSDN Magazine article titled
is out in the online January Issue here.
It's based on real issues, guidelines I've developed and questions I've encountered during the last few years teaching and mentoring teams in test driven and agile development, and contains general rules I think no person writing unit tests should go without. It took blood sweat and tears to make this one, and I hope you like it (though the editor seems to have thoroughly cut down large pieces of it including changing all my samples to be VB.NET instead of C#.. especially the part that says that this article is targeted at developers using any version of a unit test framework out there.. grr!)
Anyways, here's the summary:
"There's a lot of talk these days about unit testing and how one should go about writing unit tests for their applications under different scenarios (for starters, see my June 2005 MSDN®Magazine article on testing your data layer, available at Know Thy Code: Simplify Data Layer Unit Testing using Enterprise Services). That means there are a lot of developers who say to themselves (and to their teams) "Hey, we should start writing tests, too!" And so they begin writing unit test upon unit test until they reach a point where the tests themselves become a problem. Perhaps maintaining them is too hard and takes too long, or they are not readable enough to make sense, or maybe they have bugs.
It is at that point that developers are forced to make a tough decision: dedicate precious time to improving their tests or ignore the problem, effectively throwing away their hard work. The cause of this problem is simply inexperience writing unit tests.
In this article, I'll try to bring you some of the most important practices I've learned over the years while developing and consulting, and while training developers. These tips should help you write effective, maintainable, and robust unit tests. And I hope this advice helps you to avoid huge amounts of wasted time and effort."