Unit Tests, Testing Frameworks, and Continuous Integration, a Time Investment Worth the Price
Time invested into writing unit tests should never be deemed as time wasted. In fact, it should be viewed as just the opposite: time saved. As a former rejecter of writing unit tests, it only took one large scale project to radically reverse my views and accept unit tests for what they are: time savers and debugging assisters. The best thing about the adoption of unit tests is the utter fact that it is never too late to begin writing them. The simple selection of an open source testing framework will instantly begin enhancing the quality of your company, team, or project’s solutions.
- Choose a testing framework to write unit tests against. As a C#/.NET specialist, I elect to use nUnit.
- Determine a universal guideline for your company, team, or project to follow with regards to unit tests.
- How thorough are you going to write your unit tests?
- What code coverage percentage are you looking for? (Discussed later)
- ITERATIVELY implement functions of your application followed by your unit tests.
- As a back-end developer, I often will implement a significant chunk or segment of a service and then follow it up with the unit tests.
- Personally, I write unit tests to cover all possible code paths and parameter scenarios. While this is not the industry standard, be sure to utilize this step to follow the universal guidelines set forth for the project. You do not want half of your application to have 100% code coverage and the other half have 50% coverage. Consistency has a direct correlation to quality.
- Do not significantly advance your implementation until all of your unit tests pass.
That wasn’t so bad, now was it? But wait … there is more. You can use your unit tests to leverage more out of your solutions. The first is code coverage reports. Code coverage is a measure used to determine what percentage of your implementation is hit at some point by a unit test. A code coverage framework will simply read in a class library that has test fixtures in it and generate a report. The second, and personally my favorite, is Continuous Integration.
In summary, unit tests have increased the productivity in our team by keeping us fixing broken code instead of debugging it. Continuous Integration has kept our team up to date by the minute as to whether or not we can release a new revision of our solution into production should the need arrive. The investment spent writing the unit tests were justified on more counts than can be remembered. There truly is no way to know if a complex system will continue to work properly when integrated components are re-factored late in the project without strong unit tests in place to assist.