It seems really weird. I've been trying to get an answer to the question "what popular apps have actually been built using TDD?" for a while, without success. All of the entries on his list are either libraries, programming languages, or testing tools and frameworks. Can anyone name actual apps that TDD has blessed us with?
Much of IMVU's client and website (tens of millions of customers) were written with TDD. I've long been a proponent of TDD once you pass the prototyping stage and you need to write a production-ready component with [most of] the edge cases figured out.
The "red green refactor" loop is more like:
1) What's the next problem this software needs to solve?
2) Write a failing test that demonstrates the missing need.
3) Implement said behavior.
4) Refactor until you don't see anything else to refactor.
I think step #1 is one of the most important and yet I don't see much discussion of it. Pick the most "key" tests to write first, whether that be your happy path or the functionality that has the most risk.
On refactoring... I work with people who TDD all of their work and other who write unit tests afterwards. In my experience, those who test-drive are more comfortable refactoring otherwise. When I was test-driving imvu.task ( http://thespeedbump.livejournal.com/63798.html ), I spent a great deal of time just staring at the code after it was written... it's very continuation-heavy code... and suddenly I saw a refactoring that collapsed it by 1/3. We've hardly touched the code since. It solves the right problem with the right amount of code and I think it's only had a couple very obscure race conditions.
In summary, TDD is one of my favorite tools for focusing my efforts so we build what we need, but only what we need.
More importantly, that were done with TDD as opposed to unit testing, testing with a repl, etc.? A lot of claims about TDD's benefits seem to take credit for testing in general. (Automated testing is a clear win, IMHO.) Insisting on writing tests upfront does mean that you test consistently, but then it's hardly the primary cause.
I'm sure it's a highly useful tool in some cases, but the people pushing it uncritically make it harder to tell when it's actually a good fit. In my experience, it's very useful for safely making changes in a legacy code, but I suspect it can encourage over-engineering surface details or getting caught in local maxima when used for initial design. (I usually just design with a REPL or notepad/whiteboard.)
> All of the entries on his list are either libraries, programming languages, or testing tools and frameworks.
I've never used or looked much into TDD, but it seems to me that that's where TDD would be best: areas where input is easily done programmatically & where output can be easily checked for whatever property. How does one test a big GUI app - write some sort of binding to xlib to move the mouse around and go through routines? I'm sure it's possible, but I suspect it's pretty difficult to come up with useful but reliable tests.
That's true of automated testing in general, really. It helps to design the GUI as a thin layer around a bunch of code that can be tested, scripted, etc. in isolation, rather than tangling the major functionality with the GUI code itself.
It's hard not to see that as a list of clients of consulting firms rather than a list of serious open source software built with TDD.
I know the Rubinious project was built aiming to use TDD and it doesn't seem to have gone anywhere YET. As far as I can tell, a compiler is one beast that needs a strong abstract design first rather than a set of tests first - but I'm prepared to be surprised.
Pivotallabs lists Twitter first but I would be rather surprised if someone could verify that a substantial part of Twitter's app has been built using TDD (go ahead, surprise me).
One of the comments on the original post claims open source apps don't count because they "are not subject to many of the challenges the average developer faces in a corporate environment" so it appears TDD fans can't win either way.
But since you're looking for open source success stories there was some very positive noises about TDD from a Twisted dev recently:
"I would strongly recommend at least practicing some TDD, too. Learning how to write tests was useful for me, but practicing TDD really expanded my design skills in a bunch of surprising directions that were almost unrelated to testing. I originally felt as you do, that I wasn't disciplined enough to do it; now I feel like I'm too undisciplined not to do it ;-)."
Though he specifically states that Twisted didn't start out TDD, which he regrets, but maybe that disqualifies it.
Regarding Rubinius (and JRuby that was listed in the original post) I'm not sure trying to create a spec for an existing language implementation and then try to meet it would count as "true" TDD if people care about such differences. But maybe they do TDD for other bits lower in the stack, I'm not sure.
I've only scanned the Rubinius code and noted their blogs/announcements but ... it seems like they shifted from one basic model of their virtual machine to another in the middle of their process and I'm quite skeptical that this either indicated they doing well or that it would be considered a victory for TDD. Looking from the outside, it looked more like "we thought that TDD would let us get by without design but we were wrong...".
I've heard TDD described as "write a test, write a function, repeat" and THAT is not enough. You definitely need a guiding design as well.
I worked as a consultant at Twitter for a while [summer 2008] and saw no evidence of TDD in action. More like - someone monkey patch the running server, we're on TechCrunch again!
