Ignoring the obvious benefits after the code has been written, I am interested to get a rough idea how much productivity is initially lost, or how much extra time is initially required, due to the requirements of TDD.
I am aware of the benefits of TDD and the productivity gains that come from writing less buggy code, I am just interested here in understanding the initial cost of implementing it.
If you are starting with fresh code (which TDD implies) there is very little cost. Think of a condition your code needs to adhere to, write the test scenario, and attempt to build the project. The project fails because there is no code to test, create the code to test, build again and your away.
The advantage of this style of development is you don't over engineer your code trying to make complex facets that serve little purpose other than elegent (or esoteric) code. You only write code that moves you closer to your final goal. At every stage of the process you can easily see if all the prior code still works completley.
The answer is, of course, it depends. I find that the more complex the problem, the more time I save using TDD. When I'm testing as I go, I tend to get everything right the first time, as I'm exercising the code as I go. When I try to 'just bang it out', I find that I tend to get complex or nested bugs which are harder to find. Of course, your mileage may vary.
It sounds like you're skeptical of the benefits. I would suggest doing some paired programming with someone who has TDD experience, as you will gain a lot of independent skills. I don't think I've ever heard anyone argue that TDD is a waste of time, but just that the amount of testing may vary according to the complexity of the problem.
It depends largely on the experience of your team with TDD and the test framework(s) you choose (to determine the learning curve), and the size of your project. On a small project (say, less than a month of calendar time) with a team that hasn't used TDD before, I would estimate the time is 100% more than your planned development time.
On your second and future projects, this time goes down dramatically as the team is more comfortable with the test framework, and all the needed tools are installed and handy. If you have a mix of staff experienced with TDD (and still a small project) the initial penalty is probably closer to 50% or less.
For larger projects, the productivity gains will quickly overtake the overhead of TDD, especially as the team size goes up. So, for example, for a project with six months of development time, and a team size of five or more, I wouldn't budget any additional development time.
In my experience, you tend to write 2-3x as much unit test code as the implementation code it is unit testing (if your unit tests are thorough, that is). If you're doing automated integration tests, those are usually a little less complex than the unit tests, so add maybe 1x the implementation code, or even less.
If you're not familiar with writing unit tests, you should factor in the ramp-up time of learning how to write proper unit tests, use mock objects (such as with EasyMock), etc. Many people underestimate how much ramp-up there is, but without the right ramp-up, you end up writing crappy unit tests.
The learning curve for TDD is significant and ongoing. Teams that are learning TDD from scratch may often have to learn new ways of coding to effectively support TDD.
While this can slow down the rate at which application code is produced. There is immediate benefit in the quality of the code and the team's understanding of that code.
If you have not implemented an application that uses TDD then you might find hard to get started. But after some time you will feel right at home. Also, it is important to note that TDD behaves like a safety net for your application. This means that if you change the application design at one place your unit tests will help you catch any problems that arises due in other parts of the system. Also, make use of the Mock Objects and only test what is required.
Sometime when testing the interface you don't need to test whether that object got persisted in the database or not. In other words you don't need to check for persistence in all of your tests.
What if I rephrase your question a bit, and change "TDD" to simply "testing":
I am interested to get a rough idea how much productivity is initially lost, or how much extra time is initially required, due to testing.
First of all, I'm not going to argue that TDD is the same thing as application testing. But, it is obviously a form of testing, and it could easily be grouped alongside application testing in terms of QA. Yet, you'd never hear a programmer asking how much time he needs to "waste" by testing their software, because most programmers simply don't test their own software very thoroughly. In fact, the vast majority of programmers I've met check to see that their code compiles and runs as expected, but usually leave it to the beta testers to do the rigorous testing. They are satisfied when they see that the software runs how they would expect it to run, but it's very hard to test from the end user's point of view when you wrote the software, since you programmed it and already know how it should be used.
However, since TDD involves programming, many developers perceive it as lost time, since they view this as time that could be spent writing application code instead.
I think the better question is, how much time would you be willing to devote to testing in general? If you're ready to say 50%, then dedicate 50% of your hours to programming, 40% to writing test cases, and 10% for higher level application testing (for example). But I would say spending 30-50% of your time writing test cases is a reasonable estimate, and I've heard this same number used by some project managers as well.
Also, keep in mind that TDD advocates using test cases as a debugging tool, not just during the design phase of your software. So when a user reports a bug, the idea is that you first write a test case which replicates the problem which they experience. Then you fix the software so it doesn't happen again. This time, which normally might be billed simply as "debugging", also technically counts as writing test cases, even though you are actually fixing existing code.
Interesting question. I recently picked up TDD as part of my last project and since I am very new to the TDD process take this response with a grain of salt. I thought I would give you some examples from my experience to help give some perspective.
My last project my core tasks would be broken into 2 week chunks. This worked out to a single development cycle where I would design the component, write the tests and then code the component. My first week was spent gathering requirements and write a small spec (not very agile but it helped to justify what I did). Next I would spend a day or two writing tests. After the tests were written I would implement the components for about 3 days and then continue debugging/adding new tests until the cycle was finished. This is inline with the 30-50% estimate found in the previous post.
This amounted to a large amount of time writing the tests cases but while I was implementing the code things went alot smoother. Even as I would continuously modify the classes under tests and refactor the tests continued to be worth their weight in gold.