TDD improves quality! That might sound obvious, but evidently it isn’t. Test driven development (TDD) is often cited as a key agile practice (1,2). But still, the evidence has been equivocal until now. [bibshow]
What is TDD?
If you already know what TDD is you should probably skip this section. If not, here is a super-brief recap of TDD. The traditional approach in software engineering and virtually every other discipline of engineering has been plan-do-check. So for instance, when building a house first someone would do the plans, then the plans would be checked. Then the house would be built according to the plans, then the building would be checked and so on. It turns out that fixing problems after they occur is costly and time consuming.
TDD is an XP or eXtreme re-take on this cycle. If it is good to test things earlier, then why not test first and do later? Then the approach becomes check-do instead of do-check. This probably isn’t very helpful if you are a beginner. Perhaps you should read more here?
Systematic Literature Reviews and TDD
So far, systematic literature reviews on the topic have come to different conclusions. But now, Munir, Moayeed & Petersen have approached the problem a bit differently… They have also performed an SLR but. [bibcite key=”citeulike:12927131″] Wait, first let’s have a look at SLRs and their growing role in software engineering research.
In recent years, there have been quite a few systematic literature reviews (SLR) in software engineering. It doesn’t stop there; there have been SLR:s of SLR:s etc. [bibcite key=”citeulike:3577768″] A Google Scholar search returns 224 hits for the search “intitle:"systematic literature review" "software engineering"“.
There has been an explosive growth in publishing systematic literature reviews in software engineering.
An SLR often starts out with a selection of perhaps a thousand relevant articles, papers etc. The researchers then work to reduce the list by excluding irrelevant work. What if there was set of criteria that could be applied to this exclusion process that would make the SLR even more systematic? Ivarsson and Gorschek suggests that there are two such criteria: rigor and relevance. [bibcite key=”citeulike:7973764″]
This is exactly what Munir et al did. They divided the work they found in low and high rigor and low and high relevance. Then they focused their review on only those papers and articles which had both high scientific rigor and high relevance for the question at hand.
Conclusion — TDD improves quality
The conclusion was that TDD improves extrinsic / external quality and that it increases cost / development time. Nothing could be said about intrinsic / internal quality. So is TDD worth it? Yes, if you prioritize quality.
And honestly, you should because without quality, you won’t be agile. At least not in the long run. Trying to be agile with low quality is like trying to build your house on soft mud. It will collapse and you’ll just have to hope that no one is on the inside when it does.
Just as TDD improves quality, so does applying a strict logic to SLR:s improve them I suppose. Or perhaps that is just wishful thinking because I want TDD to be a good idea, I rejoice when someone finds a way to show that it is? Anything that can ensure that the explosive growth in SLR:s that you can see in the chart is matched by an equal explosion in quality must be a good thing.
References
[/bibshow]
Featured Image
The featured image is by Eric Lefevre-Ardant on Flickr. It is from a speech on TDD and is used under CC BY SA 2.0.
Research Blogging
H Munir, M Moayyed, & K Petersen (2014). Considering rigor and relevance when evaluating test driven development: a systematic review Information and software technology DOI: 10.1016/j.infsof.2014.01.002
Image sources
- Test driven development – ten years later: Eric Lefevre-Ardant | Flickr | CC BY SA 2.0
