There are as many definitions of unit test as there are unit testing frameworks. My favorite definition is from Roy Osherove.
A unit test is an automated piece of code that invokes the method or class being tested and then checks some assumptions about the logical behavior of that method or class. A unit test is almost always written using a unit-testing framework. It can be written easily and runs quickly. It’s fully automated, trustworthy, readable and maintainable.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
This quote is from Roy’s excellent book; The Art of Unit Testing. I encourage you to buy a copy as it is contains plenty of unit testing wisdom.
Visual Studio 2010 contains a unit testing framework, and I’ll show you how to use it to automate your own unit tests. Not all code in a class needs to be tested, only if it has logical side effects. Look at your code. Does it make any calculations or decisions? Does it contain any if blocks or switch/case statements? If so, then a unit tests helps you evaluate whether that code is working according to your assumptions.
Note that if your test code opens a database connection or modifies the file system it's more appropriately categorized as an integration test. Integration tests are useful in their own right, but I’ll cover those in another article.
I have a simple class with one method that needs a unit test. The intent of the method is to calculate a payment date thirty day in the future. Payment dates must be on a weekday so if the candidate date falls on a weekend, it needs to be adjusted to the next weekday.
As I see it there are two obvious tests.
1. The calculated date must be at least 30 days in the future. Since that date could be on Saturday or Sunday the other valid dates are 31 days and 32 days from the input date.
2. The calculated date cannot be on a Saturday or Sunday.
Here is some sample code to generate the payment date. If I were following a Test Driven model I would write tests first, and then flesh out the production code. Due to space limitations however, I will just show you the finished code.
There is an error in the code, the case statement for Sunday is incorrect, it should add one day to the temp date, not three days. Writing a suitable unit test should catch this error.
Creating the Unit Tests
For convenience, Visual Studio 2010 can create test stubs based on your existing code. You tell VS where to find your main project and it creates a collection of test classes and methods. I prefer to have the test code in separate project but Visual Studio is flexible and allows you place the generated code in the same project as your main code or in any other project.
What about the generated code itself? It gives you a decent starting point, but I usually rip out a modest percentage and replace with my own before I’m ready to run the tests. But it still can be useful so let’s start by looking at how to create the Unit Test Project.
Visual Studio generates some code for us. The two key items to note in the generated class are the [TestClass] attribute added to the class and the [TestMethod] attribute added to the TestMethod1 method.
These attributes instruct the Visual Studio test runner to instantiate the test class and run the test method.
Read about renaming the method in part two.