A unit test is a piece of code written with the sole intention of verifying that a routine or function behaves as we’re expecting it to. Unit testing attempts to provide a collection of tests to check every method of the different classes the developed program may contain works flawlessly. The general idea is that, if all the parts of the program work properly independently, it’s highly likely that the program as a whole will function as expected. Of course, after all the unit tests are passed, integration tests must be performed as well to ensure the complete system doesn’t have any unintended behavior.

Those who have never tried unit testing before might be wondering right now… so, you’re saying that we need to write code that isn’t destined to make the application work? As if regular coding wasn’t hard enough! Well, keep in mind that these isolated tests provide different basic advantages:

• Unit testing promotes change: It facilitates a programmer to rewrite some code to improve its structure, architecture or performance (what is called refactoring). These tests will be run afterwards, making sure the code still has the same functionality as before.
• Unit testing simplifies integration: If we apply unit tests to all the different parts of our code, once we reach the integration phase we can be certain the code is actually working properly. This way integration tests will be simplified and the time spent in this phase will be highly reduced.
• Unit testing documents the code: The very tests themselves tell other programmers how to use the code and its intended behavior.
• Unit testing facilitates and promotes separation between interface and implementation: Since the only interaction between test cases and the code being tested are their interface, any change to them must be done without changing it.
• Unit testing make errors bounded and easier to locate: since you’re checking the behaviour of a small piece of code at a time.
• Unit testing discovers bugs very early in the development process: always remember that the effort to solve a bug is not a linear but an exponential function in time: the more time elapsed from the writing of the code till the discovery of a bug, the more difficult it will be to remove it. The majority of bugs of a module must be taken care of before marking that module as finished.

Unit tests are a fundamental tool to catch bugs early in the development process. I will never get tired to repeat that bugs must be discovered as soon as possible: if a bug is discovered in pre-production phase it will most likely be extremely difficult to take care of… or it might not even be removed at all!

Although I mention some of the benefits of using unit tests here, I can’t really explain how much your experience as developer will improve by using them! If you start writing unit tests for all the code you write, you will very shortly start to produce modules with many many many less bugs than before, making you a faster and more productive developer, and improving the relationship with your boss and clients.

So, if I have already convinced you of how convenient the habit of writing unit tests is, take a look at NUnit. NUnit is the most used unit testing framework for .NET and Mono. It is open source, and has a whole bunch of documentation available, so it shouldn’t be very difficult to get started with it.

Just to get an idea of what NUnit is about, here’s some example code:

using NUnit.Framework; 

[TestFixture]
public class NUnitExample
{
    [Test]
    public void Test()
    {
         Assert.AreEqual(10, 5+5, "Add");
    }
}

Simple enough, right? Well, trust me when I tell you that it can really get much more complicated than this… but still, this will give you an idea about what this whole thing is about.

Now, you have to keep in mind that, as with all writing of code, the quality of unit tests depends on the programmer. If you write bad unit tests, then you won’t have advanced a great deal in discovering possible bugs. Unit tests are not miracles, they are just one more tool you have to do your job better.

But as true as this is, I totally recommend you to start trying out unit testing ASAP! Don’t be lazy to start writing unit tests! The time you loose today in writing one will be recovered tomorrow multiplied by a factor of 10. Once you have the habit of always writing unit tests, you’ll see that you’re much more productive than before.

You just must keep on practicing writing unit tests. As all things in life, the more you practice, the better you’ll do!

Related posts:

1. Improving software quality: automatic testing
2. GUI Testing
3. Test-driven development
4. Load testing
5. Some open source projects for .NET you should take a look at