Does TDD(test driven developement) always outweigh cost associated with it?

Question

I am just curious.

Answer 1

No. TDD cannot outweigh the cost for ALL projects simply because one can easily construct a trivial project that would require more time to write test for than to actually do the work for. For example, a program that takes any of 6 different inputs and outputs x if there is more than 2 inputs, and y if less. You would need to write a larger test, by far, than the actuall program.

However, that being said, TDD almost always outweighs the cost. The tests serve as the spec, so really it is just a hyper-detailed, or rather a concrete, specification that the project is being built to satisfy. This will catch bugs right away, and since you code to the tests, you can't forget to test things as easily as if you test to the code.

Answer 2

In my opinion, not always.

For instance, if you inherit a large legacy codebase which is perhaps poorly architected then adding tests to even test small additional features can be prohibitively expensive. In these cases I believe that extensive code review is a better investment.

In general, I would always recommend TDD for new projects, or even existing projects where end-user failures are unacceptable.

Answer 3

Wow, this one's gonna start a war! Well, here's my two cents.

TDD has the potential to outweigh the cost associated with it. In an ideal situation, the time that you spend writing tests should be returned to you in time saved while refactoring or modifying the code (because your tests should catch a good portion of bugs you introduce, and because the code resulting from TDD tends to be very modular). You should also see a substantial savings in time spent fixing bugs found by QA, because a good portion of your bugs will be caught by your unit tests before QA ever sees them.

On the other hand, TDD takes some significant learning on the part of all members of your team before you'll see full benefits from it, and this can cause significant drag early on (which is why a lot of teams drop TDD early on as "too expensive"). If, for whatever reason, some of your team fails to fully grasp the subtleties of TDD, this drag can go on for quite some time.

So I think the answer is essentially "Yes if done right, No if done poorly."

Now, does TDD make up for its cost when you're pair-programming? That's a whole separate question...

Answer 4

Not always, but usually. Much if not all of the upfront development cost added by using TDD is returned during maintenance. It's true that the tests have to be maintained as well as the application code, but in my experience it's much easier and faster to maintain code that includes unit tests.

Answer 5

Personal opinion (surely this is a subjective question?)

On a long enough timeline all projects gain from TDD

The trick there of course is judging the timeline from the start. Very small projects which serve here-and-now purposes or which will genuinely not go beyond your personal hands (or won't matter if it does) might fall below the curve, and there's an argument that introducing unit-tests to a very messy legacy project may be beyond realistic ability (but then why are you not rebuilding froms scratch? -this time with TDD).

Answer 6

No methodology always outweighs the costs associated with it. You have to use the right tool for the job. However many methodologies are similar in cost so it may not matter which you use, as long as you use it well. Finally it's very hard to measure the benefit of a methodology without years of data, since you have to consider the entire lifetime of the software under development. Maybe version 1 is really hard to do, but then versions 2-5 are super easy because of the investment. Or maybe version 1 was hard to do, but you feel you invested well, but you'll find that your long-term planning was off and now version 2 will also be hard to do because you have to rewrite stuff from version 1.

Answer 7

Questions with 'always' or 'never' in them are rarely interesting; this is, unfortunately, no exception.

Answer 8

TDD is great when you know what you want and you can specify it to the level of detail required to write tests but occasionally, you'll be faced with a project where the number one challenge is simply to figure out what it is that you're trying to build. In these cases, TDD can prematurely lock you into a sub optimal path. Instead, a better approach would be to work on a couple of throw away, low fidelity prototypes and THEN write tests.

Answer 9

I think this question needs a bit of perspective:
TDD is a tool/practice for developers to use as part of a process. In fact there are lots of ways developers can work - and they all have their associated costs. The question comes down to this: Who is going to pay those costs?
The answer is the customer - they always end up paying the costs. But they perceive to have received value in return - greater value than the costs.
This means that the derived value of virtually every process must outweigh the costs, otherwise it would be uneconomic and there would be no customers.
Maybe the real question is, which development processes/practices/tools are the cheapest? Some would say: Those operated by the best developers, ie its the skill and experience of the developers that counts for most.

My point of view is that TDD is capable of offering the lowest cost. In fact, I believe that TDD can reduce some of the other costs associated with software development which means that you could say that TDD has a negative cost!