Getting started with unit tests in C#

As a first real post, unit tests seems like a good idea since you are supposed to write unit tests before the real code. Most developers would agree that they are really great when properly maintained, but not a lot of developers really want to write them.

From my experience, projects fall in to one of three categories when it comes to unit tests.

  1. Little or no unit tests – Either they started doing tests in the beginning of the project and when the horrible deadline started getting close the just skipped the tests or the project were in panic mode from day 1 which means no tests. This will lead to project type 2.
  2. The project has been active for a good while, with little or no unit tests, and suddenly everyone wants full test coverage. This leads to a massive effort from all of the developers (or maybe some consultants) to get 100% coverage. The quality of the tests will probably be crap since only coverage counts and the tests are useless.
  3. The developers in this project has been in a type 1 or type 2 project before, so they are really motivated to write the tests before the implement the function. The coverage might not be 100%, but the quality will be top notch. Even when the deadline is getting closer they will persevere and keep writing those tests because they know that in the end, the will save a lot of time. Every now and then they will find some bugs with help from those test.

This is at least how all projects I’ve been working on could be defined.

Even though I really hate writing tests i really enjoy having them, so type 3 is the way to go. Hell, I even write tests for my personal projects every now and then.

Writing your first unit test

Project to test

First up is to create a project to test, and for today I will go with a class library. I create a project called MyLibrary with one single class called MyClass:

Nothing fancy, but it will do to demonstrate unit testing.

Test project

The next step is to create a test project. The wat to do this is just to create a new project in the same solution as MyLibrary and select “Unit Test Project” and name it. You will also need to add references to MyLibrary.

Add new "Unit Test Project"

After the project is created you need to create a new class, mine is called “TestMyClass” is just an empty class without methods.

In order for Visual Studio to find the tests, the class needs “TestClass” attribute, the methods needs a TestMethod attribute and needs to be public like this:

 

The next step is to write the actual tests. We will start with a simple test that just calls ToLower with the parameter “Foo”. If everything works like it should, we should get “foo” back.
If you have read the tutorial on unit test on MSDN you probably noticed that they use the pattern “Arrange, Act, Assert” which I find pretty intuitive.

This means that you first set upp everything, call the method to test then check the return value. For our class that means:

After you’ve added this to your test class, you run the test by going to Test -> Run -> All test. Now Visual Studio will MyLibrary and TestProject, open Test Explorer and run all tests and the result should be something like this:

Test result

When testing your code you should test all possibilities, and one of them testing for exceptions. You could of course do this by a try/catch around your method, but a more elegant solution is to add “ExpectedException” attribute to your class. In our case a test with null would look something like this:

This is two small examples of unit tests just to show you how it could be done to get you started writing your own tests. MSDN has a pretty good article series which is probably a good idea if you want to dig deeper. You can find it here.

Organizing your tests

I guess you could do any way you want, but having a clear naming convention helps you find the correct test within seconds and when a test fails, you know why immediately.

Naming classes

First off, every single class get there own test class, so if your tested class is named Foo, the name for the test class should be something like TestFoo.

Naming methods

I like to name it Mehod_Params_Result, so if the function is Add with parameters 3 and 4, the name for that test would be Add_With3And4_7. I think it’s a simple and clear way of naming methods. Although, if you have a lot of parameters it will be a mess.

I also think that each test should be kept in a separate method.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *