Jeremy Miller adds to my comments on the ratio of test code to production code to point out that you should not let the put you off. It is a great amplification because my post was not intended to frighten anyone thinking of approaching TDD, or be used as a reason not to.
I would add that when you use TDD the usual ratio time figured at 1/3 design; 1/3 code; 1/3 test begins to come apart, so if you are using ratios to figure project costs from developer estimates you need to re-figure these. The reason is that TDD reduces the design ratino is that the the act of designing is subsumed into your tests. That is the essence of what TDD is and why some folks prefer Test-Driven Design as a name. You reduce the testing phase because the quality of code produced by TDD will be much higher and the testing phase can focus not on finding programmer bugs but on ensuring that the user’s expectations have been adequately captured by the design.
Finally work in terms of total cost of ownership, not cost to live. Project Managers often get pressured to hit certain dates – the cost to live – because it is seem as reducing cost. This can lead to quality shortcuts to ‘get-it-live’. However, software spends 80% of its life in maintenance so these shortcuts will increase your total cost of ownership over the long-term by making your software less amenable to change. This is the notion of technical debt, making shortcuts now that you have to pay for later. I’m sure we have all been on projects that decayed from too much ‘deficit buget spending’ to the point that the development team expended all their effort servicing the debt instead of adding new value. Sadly the managers that spend the future are often no longer around when the team has to start making loan payments. Once you get too much debt you end up bankrupt and have to re-write the software from scratch. TDD helps you make sure that you ‘balance the books’.
BTW, you should also consider estimating and planning and design activities btw, essentially focus on design-all-the-time over design-up-front. For my estimating and planning, usually the act of breaking the required stories into tasks, implicity suggest a design. Try to get as much of the team involved as you can as this spreads the knowledge and encourages buy-in from the team members.