I want to start by making it clear that I know why testing is good, and that it’s really important, but I think that the TDD proponents are glossing over the most difficult part of a project.

I would very much like someone to address the issue of modifying code that is not new, and not already perfectly tested (or even completely specified!).  That is to say, the vast majority of actual code out there.

TDD is intensely focused on the early development phase (or at least TDD proponents are), and on writing new code, as opposed to what the majority of software developers actually do; maintain and update existing code.

It’s really straightforward (and fun!) to write entirely new code in the TDD fashion.  I’ve done it for about 3 decent sized projects now (one Java and two Rails), and it can be really pleasant, and a great focusing tool.  No arguments there; when you do it from the start, it’s really wonderful.

On the other hand, when you’re making incremental changes here and there throughout a very large, pre-existing, only partially tested codebase, it’s vastly less pleasant to try and do it test-first.

The Ruby Autotest tool is not such a pleasant tool at that point.  You stop wanting to write failing tests, because fixing it means autotest is going to try to do a full retest, which sucks for developer flow…  Even if your tests take ‘only’ 5 minutes to run, breaking a test makes you wince, and writing a failing test and then fixing it is for masochists only (and ones who want to miss the project milestones at that).

The focus of every presentation (this one included) I’ve seen on TDD being on the start of a project makes me wonder why nobody’s talking about later in projects…

Nearly every developer out there is going to face a large codebase with poor testing coverage, and will have to make changes that aren’t entirely new code, to existing code that isn’t entirely tested.  Does TDD have a solution for the ‘large, crufty codebase’, or is it suited only for 1.0 versions, small projects, and projects that were TDD from the start?

This isn’t really a rhetorical question for me.  I really want to get my organization’s culture more oriented towards testing.  I’ve got buy-in from lots of people that when they’re writing new modules and services, they’ll do it test-first (or at least ‘test around the same time as the code’, which is all I can ask for at this point), and that’s great.  But has anybody developed any tools to make TDD better suited to maintenance and improving existing code?

–  Morgan

p.s.  I’m skipping BDD entirely, because BDD is so hardcore in the ‘only for already very well specified solutions’ camp, that it’s meaningless for this question.  I’m also using ‘TDD’ and ‘test-first’ interchangeably, and I probably shouldn’t be.

p.p.s.  The title refers to how in Logans Run, everybody was destroyed at 30, so there weren’t any old people. In the world of TDD (or at least TDD presentations), there are no old projects, every one is fresh and new, so the issues that come with an old code base are never addressed.