From Effective Automated Testing, some benefits of using Test Driven Development (TDD):

• Improved interfaces and design. Especially beneficial when writing new code. Writing a test first forces you to focus on interface - from the point of view of the user. Hard to test code is often hard to use. Simpler interfaces are easier to test. Functions that are encapsulated and easy to test are easy to reuse. Components that are easy to mock are usually more flexible/extensible. Testing components in isolation ensures they can be understood in isolation and promotes low coupling/high cohesion. Implementing only what is required to pass your tests may help prevent over-engineering.
• Easier Maintenance. Regression tests are a safety net when making bug fixes. No tested component can break accidentally. No fixed bugs can recur. Essential when refactoring.
• Improved Technical Documentation. Well-written tests are a precise, up-to-date form of technical documentation. Especially beneficial to new developers familiarising themselves with a codebase.
• Debugging. Spend less time in crack-pipe debugging sessions.
• Automation. Easy to test code is easy to script.
• Improved Reliability and Security. How does the code handle bad input?
• Easier to verify the component with memory checking and other tools (e.g. valgrind).
• Improved Estimation. You've finished when all your tests pass. Your true rate of progress is more visible to others.
• Improved Bug Reports. When a bug comes in, write a new test for it and refer to the test from the bug report.
• Improved test coverage. If tests aren't written early, they tend never to get written. Without the discipline of TDD, developers tend to move on to the next task before completing the tests for the current one.
• Psychological. Instant and positive feedback; especially important during long development projects.
• Reduce time spent in System Testing. The cost of investigating (and establishing the root cause of) a test failure is much lower for unit tests than for complex black box system tests. Compared to end-to-end tests, unit tests are: fast, reliable, isolate failures (easy to find root cause of failure). See also Test Pyramid.

For me, the first point above is the most important: TDD improves interfaces and design.

Of course, TDD is not a silver bullet. I've also experienced (and dislike) the religious fervour surrounding TDD. I've also experienced many large, tangled, legacy code bases where it's unreasonably difficult to test components in isolation. All these horrible old code bases were not developed with TDD. Would using TDD have helped? Probably. But IMHO the single most important factor in code quality is the skill and taste of the designers - not whether TDD was used.

Update: Added "cost of investigating lower for unit tests" bullet point. Added over-engineering comment to first bullet point.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.