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.
Manuel Lemos - 2014-06-12 00:20:54 - In reply to message 1 from Patrick Rose
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.
Patrick Rose - 2014-06-12 02:24:46 - In reply to message 2 from Manuel Lemos
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".
Manuel Lemos - 2014-06-12 02:46:48 - In reply to message 3 from Patrick Rose
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.
Steve Ash - 2014-06-12 10:49:32 - In reply to message 5 from Manuel Lemos
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.
Manuel Lemos - 2014-06-12 19:52:25 - In reply to message 6 from Steve Ash
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.
Steve Ash - 2014-06-12 23:33:38 - In reply to message 7 from Manuel Lemos
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.