Testing Times Part II: Why aren’t people writing tests?

In the previous post we discussed the difficulties that can be encountered when introducing automated testing into a team. Although the principles are very straight forward, many teams have great difficulty adapting to an automated testing approach. In the second part of this series, we take a look at some of the initial issues why developers aren’t writing tests.

I don’t write tests!

As discussed in a previous post, the best approach to improving a teams testing practices, is to work closely with the developers to understand the real problems they are facing. Why aren’t they writing tests? Is anything preventing them from writing tests? What are the problems they are facing when writing tests? Are they receiving enough help to understand approaches to testing?

For the developers who simply refuse to write tests, a coverage tool can sometimes be useful. By simply viewing the coverage reports on a regular basis, the teams testing efforts can be monitored. It can initially help developers to know that their testing efforts are being measured as an encouragement to write tests. If a continuous integration tool is in use, it is also possible to take the manual labour out of this task, and simply fail the build if code is added without the required tests hence lowering the coverage.

Developers aren’t stupid and so they can find ways to fake this information by simply writing tests that exercise the code without actually testing anything. Code coverage alone does not guarantee that the right tests are being written, it is simply another tool that can be used. Another approach is to ensure that a member of the test team works with the developer(s) throughout the process. Their job is to make sure they are satisfied that the deliverables passed over to the test team contain the required automated tests. Although the automated tests aren’t a replacement for manual testing, by ensuring both teams are working closely together there can be a mutual understanding and appreciation for the required testing effort. This kind of peer pressure can be a valuable last resort when all else fails.

By combining code coverage with code reviews, education and targeted reading, developers testing efforts typically improve. This is the real goal that teams should be aiming for, writing good quality tests, which overtime naturally lead to better code coverage. There are some tools that take this approach a step further, but these really are not for the faint hearted. If developers are expected to write tests, their problems have to be recognised, addressed and resolved!

BUILD FAILED: Test coverage too low…… please right some tests!

I don’t know what I’m supposed to be testing!

One of the biggest hurdles to testing adoption isn’t that developers don’t want to write tests, it’s that they are not sure what they are supposed to be testing. They are not sure what they should be testing or how they should be testing it. They are not sure if they are writing the right tests or are testing the right areas. They aren’t sure what a good unit test should look like and therefore don’t write good tests.

You can force developers to write tests, but you can’t force them to write good tests. In these circumstances, it’s fairly easy to put teams back on track (if they are willing to learn). With good example tests, lots of guidance and related reading, it’s possible to work with the developers to address the problems they are having. Pair programming and code reviews can also prove extremely useful when developers are learning to write tests. Encourage developers to ask questions and to try different approaches to their testing. It’s very easy to see what is working and what isn’t, and this feedback is essential to improving the process. Many developers are willing to write tests, they just need some guidance. Anyone trying to encourage the adoption of automated testing needs to make sure they are approachable and on hand throughout the process to answer the questions and try to quell any frustrations before they occur.

@Test
public void setFirstName() {
    User user = new User("pramatr", "pramatr@domain.com");
    user.setFirstName("Pramatr");
    user.activate();
}

Yes, you are calling methods, but are you actually testing anything?