The cost of TRD?

Test Driven Development should not be expensive. Every time I've used it personally it's been mostly quick to create excepting when I modified a test suite for a package I inherited. If you spend forever unit testing you're doing something wrong. Switch to tools like Behat and you can show that you're filling requirements to the customer in a way they understand.

I don't enjoy writing boring unit tests. I enjoy writing functional or acceptance tests because they give me value.

That is because you are not accounting the time and money that is spent redoing tests when your business changes.

For some people that never had to manage their own company developing software for their own business goals, it may be hard to understand why TDD is so bad. Once people decide to stop working for others and become entrepeneurs, that is often when they realize the problems of TDD.

I can't buy that. Writing a test for a first run at a feature should be a minute job. I'm using Behat and my test suite for the feature I'm writing took 10 minutes at most to write the first 5 scenarios.

If a requirement change loses you an hour in test time then something is up, probably there's some agile style process missing. TDD works when it's supported by the customer seeing the output of each test and signing it off as "Yay that feature is right".

It costs writing new tests and running them whenever the business changes whether you do TDD or 'traditional testing!

Your reference to entrepreneurs seems like you want to reduce your costs to a minimum upfront and that is why you don't like the cost of TDD.

Some of us focus more on customer satisfaction by having frequent robust releases and responding quickly with good products.

It seems you are neglecting that if you write tests first for every little feature that you had, overall it takes a whole lot more time.

Also tests are only simple, when the outcomes are simple. Complicated features require complicated tests, often more than one test to verify different use cases.

As for customers, they often buy things without knowing how much will be the final costs in terms of time and money.

Now when you work on your business you know that time is precious because if you delay a feature release because you spent a lot of time building tests for every little aspect, you realize that you may miss the time to market. I have seen this countless times.

But as I say, if you are not your own customer working on your own business, you will have a hard time admitting how TDD obsession hurts your business.

I dispute your assertion that it takes more time to do TDD.

You find your bugs quicker and they are easier to fix because the code is still in your mind not something that you wrote six months ago and trying to figure out what you did - overall, total development time is less if you use TDD.

And you have code ready to show the customer and ship every day if that is practicable.

But if you don't have that sort of close relationship with your customers, then I guess TDD and the rest of Agile are not for you.

You are assuming all code is easy to write tests for. In many cases you need to write a lot more code for tests then to write the actual code because it handles many complex cases that you need to simulate with tests.

I am my own customer. I write software to satisfy my request. I do not have to convince anybody else that my code works because I am confident when it works with tests.

I only write tests for code that deals with complex situations that must not fail and I am not 100% confident that it works.

Ah - now it becomes clearer - you write code to use yourself and have complete control over how it will be used.

Don't do TDD!!!

For those of us in the real world where we have no idea about who will be using the software, then thorough testing is needed and the best way to go about that is with using TDD in an Agile environment, IMHO.

Not exactly. I write a lot of components that are published in the PHP Classes and are used by hundreds of thousands of users that need them.

Some components have tests, others don't. Very rarely I used TDD because most times I am not certain that I am using the right design. So if I change the design, any previous tests may be wasted.

"I'm not certain I have the right design"

That's part of the reason you have TDD! It forces you to think about the design before cowboy coding something you later regret!