I can see both sides of this argument, and I think TDD is great in some cases and not so great in others. I have used it before, but don't use it often, as the programs I write are very difficult to automatically test. (Games, which many of the bugs have to do with whether an optimization produces a visual artifact or not etc. Not possible to test that!)
As far as time spent testing, it obviously various per project, person, and methodology. But I think you have some misconceptions about coding time. With TDD, you cannot measure test writing and code separately. Here's why. When you write code and then write a test for it, you spend a lot of time thinking about how the code is going to look while you are writing the code. You plan what the code is going to look like, what arguments are going to be passed to a function, how the code might be used by other code, etc. This is thinking time, with no code written. This is also interleaved with the actual time spent writing the code. (You are thinking of the plan while you are typing the actual code). Then you will likely do some sort of debugging at least, if not writing a test. This doesn't take much thought as you have already front loaded the thought. "Well I should print here to make sure this line is correct." >From a TDD perspective, most of the actual time is fairly the same, just shifted around. The thought process that I mentioned, of how code is going to be used or how it fits the system, instead of being hinged on the code, is now hinged on writing the test. This makes the thought process more formal than in the other methodology. Instead of thinking of one thing (how a function may be used) while doing something else (writing an if statement within some logic), you are actually writing code based on the system instead of the internal logic. Then, you write some code that makes it work. In many cases, (and in my experience) the actual code is easier to write in TDD, because it is more focused and directed. I am not writing one thing and keeping in mind other things. You think, plan, and then write to spec. It is most certainly a more formal process, and can be hard to get used to. And it doesn't work in all situations of course. But timewise it seems like all the processes are the same. Without tdd, you might, instead of writing a test per say, still spend that time writing a doc string, or just looking at where a function will be used to see what the code should look like etc. I think though that test-first streamlines things a bit. By itself I don't think it makes the process faster, and that front work of writing the tests can definitely feel slower. Further on is where you have the most benefit of having tests. And with practice you can get faster at it too. Most programmers have their own methodology that they have used for a while, so they are fast at it. Any change in that is going to be extremely sluggish until you are used to it. You should try TDD at least once for a small or medium project and go all the way through with it just to get a feel for it. If you can afford to of course :)
-- http://mail.python.org/mailman/listinfo/python-list
