Unit Testing

About 70-90% of a software developers time can be spent debugging code. This might sound like an exaggeration, but in reality, most developers spend far more time hunting down causes for problems by debugging code than performing any of the other number of tasks developers do on a daily basis.

Unit Tests are handy for trimming this percentage down significantly by providing a way to run simple tests each time small changes are made. If the tests are designed well, then any bugs exposed by changes to software or introduced with those changes, will become apparent immediately on running those tests.

There are two main frameworks for writing unit tests with Visual Studio and C#. They are NUnit and MS Test. They both provide great testing capabilities to our projects and we design software to be as testable as possible by providing layers of abstraction that hide the specific implementation of methods and properties and instead, expose Interfaces that we can use to create mocks or fakes that mimic the characteristics and behavior of the referenced abstraction. We use Moq and NMock in our unit tests. Unit tests are isolated tests of specific units of code.

We strive for complete coverage on our application code, but realistically, if we get a 70-80% coverage, we might be happy with that. The entire point to writing and running unit tests is to test our code whenever we introduce change to existing code.  If we are coding and testing often enough, our code coverage percentage will not matter as much. This value is only relevant to the developer anyway. It is a developer’s tool for judging how much of their changes are included in unit tests. 

Creating the tests requires a bit of extra effort in the development process, but the rewards are realized with decreased development and testing time, as well as improved designs and better software.