plus and minus with TDD ~ a commenter's great response to Cedric Beust.

tdd-plus-minus-snip.txt

/* this comment and its opening and closing characters takes up 80 characters */

Text below is not my own; it is copied from a comment on Cedric Beust's blog at
http://beust.com/weblog/2006/06/07/agile-people-still-dont-get-it/#comment-8577

QUOTE

Here are some of the things I like about TDD:

1. Interruptability: if you write a test first, and you get pulled away to a 
dreaded meeting, you can get back to work faster because you simply rebuild and 
run your tests to remind you of what is next and exactly what problem you were 
trying to solve before you were pulled away, since you wrote the code that would 
fail until you implemented the solution.

2. Less fragility: I’m less concerned about fixing and refactoring code when I 
can rerun the tests before checking in. Sometimes in large complex enterprise 
projects, a small change can break some distant dependency. We’ve all been there 
where we are afraid to make a change to someone else’s code because the app is 
so fragile. TDD reduces stress and makes programming more enjoyable.

3. Refactoring: a benefit from #2 is that you can keep a clean house. Nothing 
worse than code that “smells” and is not fun to debug or navigate. TDD allows 
developers to constantly refactor and delete dead code so you don’t have an 
increasingly growing pile of dung. It is much more fun to maintain a codebase 
that is 25% of the size and clean.

4. Less time wasted: when a test can pinpoint a bug in seconds that can take 
hours without test coverage, you realize that TDD can often reduce the time to 
develop software over the course of the project.

Disadvantages/Risks:

1. No buy in by developers or management: this is the biggest risk to TDD. If 
you don’t have people who realize the benefits, it will never work for your team.

2. Dependencies: TDD should be implemented in a way that has minimal dependencies. 
Depending on a database connection, network connection, web services, etc.. can 
lead to fragile tests. There has been a ton of work in this area, especially 
mocking frameworks, to get around this issue. Done right, your tests should test 
only your logic, not external components.

3. Hard to add TDD later: TDD is best to have in place before you start coding. 
It is very difficult to add TDD to an existing project. Often the application 
architecture will evolve in a “testable” way when you are using TDD. You will 
write your code and use application frameworks like ASP.NET MVC instead of 
ASP.NET WebForms for example to make testing easier and more natural.

END QUOTE