The cost of TRD?

TDD does not guarantee you have the right design. That is a fallacy.

There are always a myriad of situations that you cannot anticipate because it is not up to you to judge that your product has the right features. Over time features need to be changed or added and that affects the original design.

When you need to change or add features you will realize that your changes break a lot of tests despite the application is right. Then you need to spend a lot of time fixing the tests so they can pass. That is simply stupid. That is what DHH calls test-induced damage.

I understand that many consultants fans of TDD do not realize this because they are not developing products for their own businesses, they work for somebody else, so if their customers business fail because it needs major changes, consultants do not care, it is not their problem, actually, the more work they have, the more money they make, but that hurts customers businesses because it costs them more time and money.

sorry, I set a cost for a feature, then I write it, I found that I can not go on, and I have to refactor, reingegneerize and redefine even the feature, but I have to give something to the committer. I am loosing money/time, I just could not evitate it.

But if I give a buggy software to the committer, he would pay me less the next time. He just want something that work, and if I do not test it, I can not say it work. He say me this clearly: "I prefer to pay something more, or anyway to have a clear picture of what I can have and what it is going to costs".

Quality goes down, if I do not test code. So I have to test sometime, committing to the end user without testing is for me an irresponsible attitude.

You say that test in advance (TDD) is a waste, but writing test is far to be a bad idea, at least for me.

Ok, you are writing a project for yourself? would you drive a car that could burn during a journey with your family, just because you had bilt that car yourself and for your family?

In case it was not clear for you, the question is not whether you should have tests for your code or not. The question is whether you should write tests first before you have stable design or later when all it is more settled.

If you are not confident that your code is bug free, you can use tests to verify if it works as expected in as many test cases as possible. Still there is no amount of tests that guarantees that your code does not have bugs for cases you have not tested.

If you look at my packages in PHPClasses, some have tests, some used even TDD, but the others didn't. I write tests when I am not confident because the code is complex and has many features that may interfere with each other.

For other packages that you can't go wrong much because they are too simple, writing tests is a waste.

As for when you write code for a customer, if the customer changes his mind about his business because what you developed is not making his business progress as he hoped, that is not your fault, so he should pay for you to write new code or rewrite existing code.

In that case the tests you have written earlier are all wasted. The extra time you spent writing the tests because you did tests first, is an expense for your customer.

You will understand better how much early TDD can cost you when you are your own customer, especially if you are startup company that has no time to waste because all is experimental and subject to big changes.

No, but the tests should be part of your design phase. I'm currently rewriting the Bootstrapper package and using TDD to make sure that the API is expressive. I'm not happy with cowboy coding since then later on I'll get frustrated.

The purpose of the article is to tell those that know TDD but do not use it, that is OK to not use it, there is no shame in not do it for any reason they may have.

For those that practice TDD is OK to do it if the pointed down sides do not affect your developments.

It may as well happen in the future that when the circumstances of your developments change, you need to review your position for the reasons pointed in the article, like for instance when you work in applications for your own company business, rather then working for customers.