Achieving Test Driven Nirvana
Achieving Test Driven Nirvana
Join the DZone community and get the full member experience.Join For Free
Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.
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
- 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 , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.