[cgopalan]

Thanks for your input. It does seem difficult to find projects that have been successful in the public sphere that have solely adopted TDD as a design method (besides junit and fitnesse, which seem to be somewhat simple solutions to simple problems).

Strangely, it might be the case that programmers who have used some form of red-green-refactor TDD have realized its shortcomings, and are not eager to present that publicly, and also recognize that it cant be set in stone as the one true method to write correct code.

Maybe its time I stopped trying to research more about TDD, and just conclude that what works for writing correct programs is what has always been the workflow:

1. Spend time analyzing the problem.

2. Come up with an algorithm based on similar problems or something that makes sense to the programmer.

3. Ensure that there are tests to verify it.

4. Implement the algorithm(s).

5. Change code and tests iteratively based on more analysis.

[dalke]

You may be interested in an essay I wrote a few years ago. http://dalkescientific.com/writings/diary/archive/2009/12/29... .

"and are not eager to present that publicly"

I think http://lizkeogh.com/2012/06/24/beyond-test-driven-developmen... is a good expression of that. The author used TDD as a way to understand how to develop testable software, but then writes "Here’s a confession: I don’t always write my tests first. I often don’t automate scenarios up-front either. And I consider it right for me not to do so."

I found that page because I wanted to give an example of "Spike and Stabilize", which is an alternate to TDD more along the lines of what I do.

Your question has inspired me to write a follow-up to that 2009 essay. The main point will be that TDD is not that appropriate for non-functional testing. Beck's original definition is that everything can (and should) be structured around TDD. There are any number of quotes which use a weaker point; use TDD plus other techniques, but not TDD alone.

For just one of many examples, see http://disciplinedagiledelivery.wordpress.com/2012/10/23/str... .

That link is interesting because it highlights the importance of a QA group in agile, but calls it "parallel independent testing" or "test team" rather than the traditional name of "QA".

[cgopalan]

Just read the essay. Very informative. It basically lays down most of what I think about TDD, except that IMO, writing some tests first (which I know about) is better than writing tests last.

But thats exactly my point. The workflow for solving a problem and making sure its sufficiently correct cannot be pinned down to something as simple as red-green-refactor. Programmers have to be given the flexibility to approach problem-solving in different ways. As long as the program is correct and performs as stipulated by requirements (both functional and non-functional) it doesnt matter how it was arrived at.

Eagerly awaiting your follow-up writeup. And if you do hear of some open-source projects that have used TDD successfully, please mention them.

My goal in asking this question on HN is to have an open mind about TDD and learn to do it well. But I dont want to add that skill if it has not proven to be successful. IMO, there are lots of other skills that I could add to my toolbox that I think are more useful as a programmer.

[dalke]

That's a rather small "except", as I wrote "My own practice is to have good, automated tests, but these don't get put into place until the cost/benefit ratio makes the tests worthwhile; which is rarely at the start of the code development and always by the end." The difference between you and me is "some tests first" vs. "rarely do tests come first."

The useful skill I think should be practiced more often is of breaking code. Take a code base and find out where it doesn't scale, where it core dumps, where it sits in an infinite loop, or where it lets you write read and write arbitrary files to the file system.

It's pretty fun, but it's a mindset contrary to that of most programmers, who are optimistic and goal oriented, rather than pessimistic and defensive like me.

In my essay I'll ask for pointers to public projects developed in full red-green-refactor style.

Cheers.