PragPub 2011-11: Issue #29 by The Pragmatic Bookshelf

Author:The Pragmatic Bookshelf
Language: eng
Format: epub, mobi
Tags: PragPub—Monthly Magazine
Publisher: The Pragmatic Bookshelf, LLC
Published: 2011-11-01T04:00:00+00:00

Costs and Limitations of TDD

As with any new technique worth adopting, TDD incurs a learning curve overhead. You’ve already seen the three simple rules of TDD—that’s really all there is to it. But the “how to” isn’t the tough part. Instead, the primary challenge lies in developer habits: It’s difficult for programmers with significant experience to re-learn their core approach to building software (and even more difficult for some to accept that their long-ingrained approaches hold room for improvement).

Success in transitioning to TDD will thus mostly depend on the enthusiasm of your team members, their ability to work together and support each other, and their interest in continual introspection to recognize and fix approaches that need improvement. A team aligned with all of these conditions might have a solid foothold on TDD within a month or two. A group of individuals comprised of dissenters and apathetic programmers will likely not succeed without reorganization or intervention.

The actual labor cost of TDD is hard, if not impossible, to quantify. One study makes only the conclusion that quality increases but development slows with TDD. Other studies have demonstrated that initial development time increases from 15% to 35% but with increased quality.

The question becomes, what is the value of “increased quality?” Cost assessments for programming effort rarely include things like developer rework costs during the testing phase, the cost in delayed release, the cost of help desk/support time, the increased cost to introduce a new feature because the code is not clean, or the cost of losing a customer who leaves due to devastating defects.

TDD will not solve all development problems. It is only a portion of what is required to increase quality in your systems. TDD must be bolstered by additional testing, including some integration testing, acceptance testing, load/performance testing, and exploratory testing (to name a few). It still demands review of the software produced, and introduces a new need to review the tests as well. TDD is also not an end-all for design: You should still consider high-level up-front design, and you should still discuss design as a team on a frequent basis.

TDD is also not a substitute for thinking. While TDD derives code well for the vast majority of algorithms in your system, it will not necessarily help you with the insights needed for some complex algorithms (a rare need in most systems).

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.