karldmoore development

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

Testing Times Part III: Are developers able to write tests?

Posted by karldmoore on July 21, 2009

In the previous two posts we discussed the difficulties that can be encountered when introducing automated testing into a team and how to try and address these when they occur. Although the principles are very straight forward, many teams have great difficulty adapting to an automated testing approach. In the third part of this series, we take a look at some of the reason that developers can’t write tests.

Nobody knows anything about testing

So many teams I’ve encountered in the past don’t automate testing because neither they nor any of their team have used this approach in the past. In the previous article one of the comments from PhiLho was about this very subject.

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?

A typical response to a question like this is, What do you think about it? How would you test the method? Have a discussion about it in the team, have a debate about it. Try something out and see how well it works out. Throw it away and try something else completely different.

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. We could just lower the visibility rules, how about package private? If the test hierarchy mirrors the original source are what issues are we introducing here? Do we really need to test the method directly, won’t it be tested implicitly by executing the calling code?

All of these questions have many answers and I’m sure a quick search will yield results to prove these debates have and still rage on. The interesting part in all of this is having a go and seeing what works for your team. “I didn’t want to do it because I didn’t want to do it wrong”, is such a common attitude amongst some teams. I would actively try to convince people that you have to fall down and make some mistakes to learn, most of the time without any previous experience the only way to find out is to try! If you want to jump start this process there are many excellent blogs, discussion groups, mailing lists, forums and books you just need to search for them, ask for recommendations and see what works for other people. But if there is nobody in your team that knows anything about testing, somebody is always going to have to take the first step to encourage the learning process.

We aren’t allowed to write tests

There are still some teams out there that are not allowed to write unit tests. There seems to be a couple of popular variations on this story; people that are not allowed extra time to add unit tests to their project and managers that don’t want developers wasting their time writing tests. In either of these situations, people have to understand the positives that come from testing and how this can improve both the teams development and it’s overall velocity.

One of the biggest preconceptions about testing, is that developers who write tests deliver code slower than those who don’t. Although some developers can release code more quickly without tests, this trend doesn’t typically last. When new code is developed it requires testing, when it’s integrated with the rest of the code base it has to be tested again, and each an every time the code is modified it requires further testing. If this testing has to be performed as a manual activity, it either doesn’t get done, doesn’t get done very well or doesn’t get done at all.

It is simply too time consuming to undertake this type of testing on a regular basis. The untested code can be a constant source of recurring bugs or in the best case it just takes longer to maintain than it should. In this situation, automated testing has to be an essential part of the development process. Manually testing can start to become a bottle neck in the process very quickly. Once automated tests are written however, a development team can prevent then wasted effort of excessive manual testing.

Some developers may initially take longer to develop code with tests, but this is a common symptom of any new approach. Once developers understand how to write tests effectively, it becomes second nature to them. Developers then tend to write test-backed code at least as fast as using a logger and debugger to develop the code. The longer a build-deploy cycle takes, the more compelling testing becomes and also the more productivity gains can be achieved.

@Test
public void codeDeliveredOnTime() {
    assertTrue(true);
}
 
@Test
public void confidenceInCode() {
    assertTrue(true);
}

If the code is still delivered as expected, does it matter if automated testing is helping this process along?

Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

 
%d bloggers like this: