Unit tests in one form or another seem to be an accepted part of mainstream software development. They are generally robust, have good tools available and quick to write. Testers like them, programmers are happy to write them and, most importantly, the product owners see value in them. So what is the potential problem?
The problem is that the term “good unit testing” is utterly ambiguous, so potentially lead team members and stakeholders up the quality garden path.
If you are going to unit test, and are not blindly following protocol, you should be able to answer the following questions.
- What value are we getting out of these tests?
- Are we using our unit tests to maximum advantage (and if not why not)?
There may be push-back from programmers to answer these questions. Typically this is a play on the belief that this is “their domain” and they “just know it”. But if you are Agile, there is one team, and everyone should be interested in, and able to add to “baked in quality”.
Let’s take .NET as an example and look at a stack of unit test tools which can be used to help
- nUnit – a .NET unit testing framework
A tool such as nUnit is required if you are to create unit tests at all. There are many such tools out there but they do not enable us to say much about how well our team is using unit testing. Have the right number of tests been written? What do we get out of those tests? Are the tests being used to specify the underlying code, or are they just being tacked on as regression tests?
- nCover – a .NET unit testing code coverage and analysis tool
nCover, or similar tools, primarily enable teams to get an easy-to-understand view of unit test coverage. This is definitely a great start to really define value – you can now claim X% automated unit test coverage for regression test purposes. It also poses questions worth answering such as – is X% high enough? Why is there only Z% in component B?
Furthermore using nCover metrics such as cyclomatic complexity, you can get further value by identifying components which are complex or unwieldy and need to be re-factored before the technical debt comes to bite the team later on!
- nSpec – a .NET BDD style testing framework
Perhaps you are already using a BDD tool like Cucumber for your acceptance tests. Why not continue the approach into code-level behaviour? nSpec is a .NET implementation of the legendary rSpec. This is an excellent way to encourage programmers to truly drive all their coding using specifications that are written BEFOREHAND. The tool also produces output in English which can be used to demonstrate the value of the tests.
The next time unit tests come up in your team discussions, ask the question – what value is being added? If that can’t be answered, perhaps you should stop doing unit tests… although it’s more likely a less superficial approach to unit testing is probably needed