[ludflu]

I'm a strong proponent of TDD. In my experience its more productive, and results in better software. But....

I've been in this position before: We have a large existing codebase with no unit tests to speak of, and the business is not willing to fund efforts to refactor or add unit tests. It is very hard to add unit tests after the fact. Not impossible, but its alot of work, and business folks really don't care.

[manojlds]

TDD is test driven development. You are talking as though TDD is same as adding unit tests.

[mpweiher]

I think he is describing the (common) situation where you want to do TDD for new code, but are dealing with an already existing code-base that doesn't have test coverage and just isn't amenable to testing the way it currently is.

So you can't really do TDD for your new code without refactoring the existing code-base. But refactoring the existing code-base without good test coverage is nasty.

[atte]

In my experience, the way to approach this is to start writing tests for any bug fixes or new features added. Over time, coverage increases and the product becomes much more solid.

[rymith]

I've added unit tests to an existing legacy product, and it would have been simpler and faster to just re-write the application with TDD. The problem is that a project not written with TDD in mind often is very very difficult to decouple, and you end up either having essential sections without sufficient coverage, or you have to come up with come pretty abstract and fragile methods to test with. It's a mess.