In my experience — ergo anecdotal for everyone else — TDD works very well when you have the right language and tools to support it.
The tools I used were C#, Visual Studio, NCrunch, and NUnit. Not only did TDD work, it was also fun. Yes, fun. Not kidding. If you work in C# and use Visual Studio, try NCrunch and use either NUnit or xUnit.net and see for yourself.
If you have a language that supports contracts, TDD is superfluous. TDD is for languages that do not provide the ability to specify preconditions, postconditions and invariants. Contracts are something that has to be in the core language, not as a library bolt-on afterthought. Alas, there are not very many languages that provide that facility: Eiffel, D, Spec#, Midori M#. Some others I've heard support contracts, but I haven't played with them myself, such as Ada 2012, Clojure, Perl 6, Oxygene (Object Pascal dialect from RemObjects).
Full disclosure: I'm a D fanboy. Also a Midori M# fanboy, but alas that endeavor got crushed under the wheels of progress.
Some languages, like C++, are not amenable to TDD. The "one minute cycle" of make test, run test: fails, write code, run test: success, refactor, run test: success, check-in is nigh impossible when there is a lengthy build step for each test run. I hope C++20 will have contracts; fingers crossed. (Thanks to Gabriel Dos Reis, Garcia, Lakos, Meredith, Myers, and Stroustrup for working hard to make it happen!)
The other danger with TDD is putting in non-unit-tests in the mix with the TDD-style unit tests. When the unit tests get polluted with performance tests, integration tests, system tests, acceptance tests, security tests, functional tests, end-to-end tests, smoke tests, or behavior tests... then that's bad. Unit tests ought to be written by developers, and run in a debug build, and should take no more than a few seconds to run. The other kinds of tests ought to be written by the quality engineers (except for BDD tests in, say, Gherkin, which should be written by the PO perhaps assisted by BAs, within discussion by Devs & QE), should be run against an optimized release build, and may take hours or even days to run.
On my one project, the entire set of unit tests took seconds to run, and had about 70% code coverage. The integration tests took about 600 hours to run the full suite, if run in serial.
A couple videos on the topic:
I'm a fan of both James Coplien (author of Advanced C++; he's the second C++ programmer after Stroustrup), and Robert "Uncle Bob" Martin. I had a squeee of delight watching these two debate the merits of TDD: Jim Coplien and Bob Martin Debate TDD
Another person I respect is Rainsberger. He's a strong advocate against using integration tests as a substitute for unit tests. He comes off as a bit abrasive (which I consider passionate), and his putdowns of integrations tests is in the context of using them as a substitution for unit tests. He's not against integration tests used as integration tests where they are suited. The way I think of it, integration tests (written by QE) are at the scope of bricks and mortar; unit tests (written by Devs) are at the scope of electrons and quarks. Completely different domains, for different purposes. Integrated Tests are a Scam
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In my experience — ergo anecdotal for everyone else — TDD works very well when you have the right language and tools to support it.
The tools I used were C#, Visual Studio, NCrunch, and NUnit. Not only did TDD work, it was also fun. Yes, fun. Not kidding. If you work in C# and use Visual Studio, try NCrunch and use either NUnit or xUnit.net and see for yourself.
If you have a language that supports contracts, TDD is superfluous. TDD is for languages that do not provide the ability to specify preconditions, postconditions and invariants. Contracts are something that has to be in the core language, not as a library bolt-on afterthought. Alas, there are not very many languages that provide that facility: Eiffel, D, Spec#, Midori M#. Some others I've heard support contracts, but I haven't played with them myself, such as Ada 2012, Clojure, Perl 6, Oxygene (Object Pascal dialect from RemObjects).
Full disclosure: I'm a D fanboy. Also a Midori M# fanboy, but alas that endeavor got crushed under the wheels of progress.
Some languages, like C++, are not amenable to TDD. The "one minute cycle" of make test, run test: fails, write code, run test: success, refactor, run test: success, check-in is nigh impossible when there is a lengthy build step for each test run. I hope C++20 will have contracts; fingers crossed. (Thanks to Gabriel Dos Reis, Garcia, Lakos, Meredith, Myers, and Stroustrup for working hard to make it happen!)
The other danger with TDD is putting in non-unit-tests in the mix with the TDD-style unit tests. When the unit tests get polluted with performance tests, integration tests, system tests, acceptance tests, security tests, functional tests, end-to-end tests, smoke tests, or behavior tests... then that's bad. Unit tests ought to be written by developers, and run in a debug build, and should take no more than a few seconds to run. The other kinds of tests ought to be written by the quality engineers (except for BDD tests in, say, Gherkin, which should be written by the PO perhaps assisted by BAs, within discussion by Devs & QE), should be run against an optimized release build, and may take hours or even days to run.
On my one project, the entire set of unit tests took seconds to run, and had about 70% code coverage. The integration tests took about 600 hours to run the full suite, if run in serial.
A couple videos on the topic:
I'm a fan of both James Coplien (author of Advanced C++; he's the second C++ programmer after Stroustrup), and Robert "Uncle Bob" Martin. I had a squeee of delight watching these two debate the merits of TDD:
Jim Coplien and Bob Martin Debate TDD
Another person I respect is Rainsberger. He's a strong advocate against using integration tests as a substitute for unit tests. He comes off as a bit abrasive (which I consider passionate), and his putdowns of integrations tests is in the context of using them as a substitution for unit tests. He's not against integration tests used as integration tests where they are suited. The way I think of it, integration tests (written by QE) are at the scope of bricks and mortar; unit tests (written by Devs) are at the scope of electrons and quarks. Completely different domains, for different purposes.
Integrated Tests are a Scam