DevOps Zone is brought to you in partnership with:

I have worked in software development since the mid 90's after a few years in the aerospace industry. Initially a database specialist always a programmer, currently with java. My focus is now on helping organisations to go faster with higher quality. Scrum and Agile are often part of that change. Martin is a DZone MVB and is not an employee of DZone and has posted 10 posts at DZone. View Full User Profile

Achieving Test Driven Nirvana

  • submit to reddit

Well perhaps not Nirvana then, but at least having a suitable level of test coverage.  ;-)

I wanted to write an article around the uptake of test driven development. Scrum and agile are hard to do well. If you break these down, you often find that the components are pretty challenging too. TDD is difficult but it has gained widespread recognition at the intellectual level.  On the ground though the practice can be patchy. Why?

Before writing this article I had a look around to see what else had been written.  This article on Geiger’s Counterpoint sums up my thoughts exactly.  Its such a good article that I hardly have anything left to say.  In fact neatly I can just provide some bullet points!

Improving the uptake of Test Driven Development

Car CubaProgrammers need help to adopt test driven practice.  So how can you go about that?

  • Lead from the front: If your senior developers are not checking in fully tested code it will destroy the practice.  Its highly demoralising to be producing well tested code only to have a senior ruin it by checking in code with partial coverage.  I can not stress hard enough that the practice must come from the top.
  • Pair code and mentor the practice: I have yet to meet a developer that took to TDD right from the off.  Most people struggle to produce good code, and TDD is far from intuitive.  The best way to improve is to see good code and work with people that write good code.  So mentor and pair code to disseminate the practice.
  • Use coverage reporting: Use tools like clover, cobertura and emma to provide reports so that you can see what lines of code are covered by tests.  Make this reporting part of your build.  Encourage developers to use coverage reports to check the quality of their testing practice.  Understand though that coverage is not everything you need to concern yourself with, sensible assertions are important too.
  • Encourage discussion: Next time you find something un-tested in your codebase, create a discussion about it.  Sometimes there are reasons, its badly written making it difficult to test.  Perhaps its an  integration point.  Through discussion you will encourage the team to find a solution and write some tests.
  • Set a bar: Find a way to set a bar.  i.e find the current coverage levels and don’t allow the numbers to fall.  I worked on a project where a custom build component was added.  It parsed the clover reports, found the current coverage level and broke the build if it fell after checkin.


Most project suffer lower levels of test coverage than ideal.  Encourage test driven development and find ways to teach how it can be done.  Create dialog and get the teams to self organise around the goal of improving test quality and coverage.  Use tools and processes to support the team.

Published at DZone with permission of Martin Harris, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Shumona Kapil replied on Sat, 2012/02/11 - 12:29pm

An excellent post. I would also add – code review tests, and put the effort into your build system to deal elegantly with fast unit and slow integration tests.

Also rewarding those who succeed; although how you do that if you’re not in charge is tricky other than relying on TDD to produce a better product in a shorter time.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.