Pramatr Blog

Test-driven and test first development have become very fashionable over the past few years. Ensuring code has tests is one of the core Extreme Programming rules, but it can also be one of the most difficult to introduce to a team. Although the principles are very straight forward, many teams have great difficulty adapting to an automated testing approach. Some of these teams don’t have any existing testing strategies in place, meaning that incorporating automated testing into development seems like an unattainable goal. In this series of posts, we’ll attempt to highlight some of the common problems encountered when trying to incorporate automated testing into development.

We DON’T do testing!

Some development teams lack any formal approach to automated testing. It’s still common amongst many teams, but over time, more and more teams are becoming test infected. Testing should really be a core part of development. Gerard Meszaros captures this very nicely when he said, “Not scrubbing before you go into surgery is a no-no, and not writing unit tests is not acceptable” (from Daryl Taft’s article Agile Brings Professionalism to Software Development).

Getting a development team to buy into any new approach is a major factor in it’s success or failure. Everyone needs to understand what they are doing and why they should be doing it. Only when the team has a clear understanding of the goals and benefits of testing, can it expect to make any real progress.

One of the simplest ways to achieve this, is to simply sit down a couple of developers and get them to write some code. The essence of this is not to show the developers what they should be doing, but let them try out the process for themselves. Both developers are asked to tackle the same problem using their preferred technique to deliver the finished code. Once the first problem is complete, the developers must write down all of the manual tests that have to be executed to prove the code works and demonstrate each of these. Once this process is complete, add another problem into the mix that has a higher degree of complexity. Again, the code must be manually tested and as the original code has also been updated, those regression tests must also be exercised. Rinse and repeat adding problems until you’re satisfied the problem has become complex enough.

The initial rounds of coding are accessible to most developers and the process is typically quite quick. As the problems become more complex and the changes to the existing code increase, the time taken starts to rapidly increase. Some developers write code that works first time everytime, but for the 99.9% of the others who make mistakes when they code, this time will also include deployment, manual testing, fixing the broken code and then repeating the process.

After the process has been completed, work through exactly the same problems again (from scratch) but instead of writing out the manual test cases, get the developers to instead write an automated test. There are typically some initial questions here but most developers can easily write a simple test case, at this point we don’t want perfect tests we just want SOME tests. After solving each problem and adding the additional unit tests, run the suite to make sure the code is still working.

It doesn’t take very long for the developers to get up and running with this approach, and when this is coupled with pair programming, it can be even more successful. Once this learning process has started, developers begin to see the benefits very quickly. Some developers take longer than others to convince, but overtime, many people find writing tests is actually quite addictive. I’ve have seen teams that either sit down in pairs or switch two developers and let them review the tests and spot any missing test cases. This can actually make testing quite competitive, in the same way that people dislike criticism (even though it’s constructive), people really don’t like being told they’ve missed a test case (or five).

It obviously isn’t always smooth, but it reinforces several facts about automated testing. The longer you have to maintain code, the more complex the code becomes, the more manual test cases there are and the longer a build-deploy cycle takes, the more compelling testing becomes. On many occasions I’ve seen people finally give in and start to write unit tests not when shouted at and told to by the lead developer, but instead, when they are sick of waiting for their application to load for the 100th time and just want to get their work finished. So the hard work is done, and most of the developers might have been convinced that writing tests is a good thing! It almost seems too easy. The CVS commit logs are riddled with classes ending in the test and the job is done, it’s probably time to do a quick review.

@Test
public void writeSomeTests() {
    assertTrue(true);
}

Ok, that’s not a good start!