Agile Zone is brought to you in partnership with:

Wille Faler is an experienced software developer, architect and agile coach with experience across a number of different industries as an independent consultant. Wille specializes in backend, integration, and Java technologies, but has more recently found a passion for Scala and text mining/analysis. Wille is a DZone MVB and is not an employee of DZone and has posted 42 posts at DZone. You can read more from them at their website. View Full User Profile

Why I love Test Driven Development

  • submit to reddit

There are too many reasons to recount in full why Test Driven Development (TDD) is great: finding bugs early, getting double-sided checking of code (test vs. code, how do they match up?), it drives good API design, tests effectively document what your code is supposed to do, it saves time on regression testing etc, etc.

But the reason above all I love TDD is that it gives me the courage to change and add to code long after I or someone else has written it. I’ll know in an instant if I broke anything. Changing code I just wrote is usually not a problem, and most of the time my code is relatively defect free after years of honing my skills. But a lot of the time, I’ll write something, then let it lay for months before I see any need to go in and add or fix anything. This is the point when my recollection of potential knock-on effects of changes is starting to be poor, when I’ll struggle to have confidence my changes don’t break anything even if I wrote the original code. 

This is the point when TDD really pays dividends: months after it was originally done. I know, in binary pass or fail immediately if I’ve broken anything. Non TDD projects will usually have a spurt of productivity early on, with diminishing returns later as defects and fixing bogs progress down. With TDD the productivity will be evenly distributed throughout the lifecycle of the software, it might even increase with time, as parts can be reused, and the reuse can be quickly tested based on adding to the existing test suite.

TDD is not instant gratification, which is probably why most developers and managers don’t get it. We live in an instant gratification world. But the long term dividends of TDD in terms of courage to change things months down the line while keeping productivity even or improving are massive compared to the alternatives.



Published at DZone with permission of Wille Faler, author and DZone MVB.

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



Robert Craft replied on Thu, 2012/01/26 - 6:08am

Test-driven development requires developers to create automated unit tests that define code requirements (immediately) before writing the code itself. The tests contain assertions that are either true or false. Passing the tests confirms correct behavior as developers evolve and refactor the code. Developers often use testing frameworks, such as xUnit, to create and automatically run sets of test cases.

Spring Security

Comment viewing options

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