karldmoore development

A development oriented blog, containing anything I've been working on, reading or thinking about.

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

Posted by karldmoore on July 15, 2009

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.

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

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


3 Responses to “Testing Times Part II: Why aren’t people writing tests?”

  1. PhiLho said

    I feel the article is written for me… 🙂

    I am convinced unit tests are useful. I understand the base theory. But well, I haven’t written much unit tests so far (although I did a number of functional tests, particularly on the GUI side).
    Beside the classical problem of time, there is even some base questions. For example, I write a private method in Java doing some algorithm, pattern matching, date computation, etc. How do I test it since it is private?
    Maybe it is trivial and I just should have searched more, but you see what I mean.
    About team guidance: it suppose at least some people in the team know well unit testing. But what if you are alone trying to do UT, or even if the whole team is newbie in the field?

    OK, I promise, I will read again the JUnit manual! 😉

  2. karldmoore said

    You’ve raised some really great points and I’ve already answered these but haven’t posted the next part yet, stay tuned :-). As for specific points about private methods, there are debates out there about this but much of this is personal preference…… what do you think about it? How would you test them? Well we could use reflection but is that really such a good idea, it seems a little hacky and a complete sledge hammer for a simple problem. Could we just lower the visibility rules, how about package private? If the test heirarchy mirrors the original source are what issues are we introducing here?

    I think many of these questions are just about having a go and seeing what works for you. There are so many times I hear people say I didn’t want to do it because I didn’t want to do it wrong. It’s the same thing that my dad says when he uses the computer, I didn’t click that because I didn’t want to break it. Most of the time without any previous experience the only way to find out is to try! In reality you aren’t going to break something and I’d much sooner have unit tests than not.

  3. […] Testing times Part II: Why aren’t people writing tests? […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: