Let's just state upfront that the topic of Test-Driven Development can and will cause polarizing responses among software Development Teams. People either love it or hate it.

I believe much of the controversy is caused because we fail to see TDD for what it is: a specification-driven test harness for designing and writing more straightforward software. TDD packs so much punch in the Agile community because it encourages a mindset of building what is necessary and nothing more.

Simple software is easier to maintain, more robust, easier to scale, and lacks technical debt or feature bloat. If Scrum is a set of training wheels for better software delivery, TDD is the training wheels for better (simpler) software design.

The many benefits of using TDD include the following:

• It's a specification-focused approach that reduces complexity because we're less likely to write software that we don't need
• It makes our design simpler and our code clearer
• Refactoring refines our design and makes our code more maintainable, a step often haphazardly undertaken if done without TDD's specification-driven framework
• Writing tests as specifications upfront improves the quality of our specifications and makes them more understandable to others
• The automated test suite serves as documentation for our software—the tests act as the specification, and it's easier for new team members to understand what the code does
• Having a suite of readily-repeatable tests gives us the confidence to release our software
• The resulting tests support refactoring, ensuring that we can make the code simpler while maintaining its intended behavior

Some argue that TDD approaches take longer to write code, and this is true in the literal sense because we're designing and writing specifications at the same time. However, when you consider all the other activities involved in software development, other than just "writing" code, this argument breaks down. Plus, the medium to long-term effects on our code base will result in significant cost savings. Plainly put, in my experience, TDD software has far less technical debt and far fewer bugs.

In fact, you should probably see TDD as a way of improving and validating your software design. It's a much more holistic perspective. It's testing++.