TDD and development time

Question

We are a small group of PHP developers contemplating on integrating or not TDD in our work flow to raise the quality of our web applications and at the same time eliminate the frustrating manual regression testing. My question is on the average how much development time would be added if we start using TDD?

Answer 1

TDD is not just about writing tests to protect your code. It's about tests driving the design. And so you might end up writing more code but you spend less time in design (or fixing problems due to lack of considered design).

A lot of the overhead I think would be at the initial stage while you learn how to use the various testing/mocking frameworks and understanding how to use unit tests to drive your design (briefly: write a failing test, then write the simplest possible functional code to make that test past, then refactor the functional code if necessary).

Once your team is up to speed with TDD and the various tools that you require, you guys will probably be more efficient than you are currently.

Answer 2

TDD saves time. I can't speak from the PHP perspective - don't know what testing frameworks are available - but with Java, my flow is much faster when I'm in the TDD groove. And my code has fewer bugs, so I spend less time fixing it, much less time finding the bugs. Red-green-refactor drives you, keeps you on track, moves you forward.

Answer 3

TDD forces you to think like a consumer of your code, and shifts the focus from implementation details to ease of use: "Be your own client".

As a rule of thumb, you will end up writing twice as much code.

Answer 4

There's a bit of lost time in writing the tests. However in practice I find this isn't so bad given that you're generally writing the tests while writing the code, so you're writing them in the same pass ( I find I spend more time thinking about what and how to code what I'm doing than the actual code - so writing the tests only adds to the "actually writing" part). Another way of saying this is that even if I"m writing twice the # of lines it's really only something like a 10-20% penalty.

Another possible source of lost time, and potentially a much larger one, is the rewriting you may need to do to make your code testable. This is especially true if you've got a large codebase with scattered dependancies and global state.

Of course tests will save you later when you've got to alter the code, but you probably already know this if you're thinking about writing tests.

Answer 5

I'm not going to harp on the benefits of TDD.. you just need to try it.
To answer your specific question... From my experience, I'd say the ratio of test code to production code is somewhere around 3 : 1 You can chalk up 30% more time with TDD. Of course this is assuming you've clocked some TDD time and not a beginner (in which case the buffer should be much higher)... and YMMV

Answer 6

Don't count on TDD to raise your quality. Having a quality mindset is far more important. I've seen high-quality pre-TDD code that was heavily tested - because the team members had the drive to produce a product that they could take pride in. I've seen Agile XP teams doing TDD produce absolute crap because they didn't have any pride of ownership. If you have the pride of ownership, you can produce quality code with whatever process suits you.

So there's no guarantee that TDD will improve produce better quality. However, if your team has the drive to be better, and has an innate pride of ownership in what they're doing, then TDD will give you the opportunity to produce better code, not because it will be better tested, necessarily, but because it will change how your code is designed.

TDD can improve the design of individual classes. Be careful, though. There's a risk that you'll migrate complexity of of individuals objects and into the domain of object interaction, then not test that adequately, so make sure you test at that level, too.

If you're already unit testing, TDD will make development somewhat slower initially, but the difference should taper off in a few weeks.

If you're not unit testing, then unit testing (TDD or conventional) will save you time.