When I gave a lunchtime talk evangelizing TDD (Test Driven Development), I summarised the benefits as follows:

• 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 helps 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. When you find a bug, add a new test before you start debugging (see practice no. 9 at Ten Essential Development Practices).
• 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.
• 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 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.

Note that the first point above is the most important.

Update: Some further points added later from Effective Automated Testing:

• It is easier/cheaper to write automated tests for systems that were designed with testability in mind in the first place.
• Interfaces Matter. Make them: consistent, easy to use correctly, hard to use incorrectly, easy to read/maintain/extend, clearly documented, appropriate to audience, testable in isolation. For more detail see On Interfaces and APIs.
• Dependency Injection is perhaps the most important design pattern in making code easier to test.
• Mock Objects are frequently useful and are broader than unit tests - for example, a mock server written in Perl (e.g. a mock SMTP server) to simulate errors, delays, and so on.
• Consider ease of support and diagnosing test failures during design.
• Single step, automated build and test are a pre-requisite for continuous integration and continuous delivery.
• Automation is essential for tests that cannot be done manually: performance, reliability, stress/load testing, for example.

The talk was well-received and did change both development practices and management awareness. I also illustrated each point with specific examples from our workplace (e.g. a developer refactoring without a test suite causing a rush of new bug reports from customers).

See Also

• Basic Testing Tutorial by hippo
• Effective Automated Testing
• [RFC] Discipulus's step by step tutorial on module creation with tests and git
• You've gotta have tests! by talexb
• PM discussion of Dependency Injection in Perl and C++
• Re^3: Do I have to export all variables and functions from my PM file? (example where TDD would've improved module interface)

• Re: Using the perl debugger to look at a renaming files function (on Debuggers References) (on debuggers)
• Re: Re: Re: Are debuggers good? by merlyn (aggressive approach to rewriting unmaintainable code)

Updated 19-Mar-2006: Improved wording. Also note that many of the ideas for these bullet points were derived from chromatic and Schwern's excellent Test::Tutorial talk. See also Unit testing -- module, book, and website suggestions wanted. Updated 23-Aug-2018: Minor improvements to wording (keep in sync with Effective Automated Testing). See also You've gotta have tests! by talexb. July-2019: Added See also section.