TDD Derangement Syndrome

Chris Missal 7 minutes later:

• • The Spark View Engine for .NET was written using TDD throughout.

Peter Hultgren 17 minutes later:

• • As far as I understand, the ASP.NET MVC framework has been developed using TDD.

chantal 28 minutes later:

• • If you’re looking for loads of empirical evidence supporting TDD, David Janzen’s doctoral thesis is very thorough (http://works.bepress.com/djanzen/4/). His research covers both academic and business settings.

Eric Smith 28 minutes later:

• • If you’re looking for more “enterprise” software 8th Light has a case study published about one of our large projects. TDD throughout naturally.

  • http://blog.8thlight.com/articles/2008/10/2/fidelity-life-case-study

Dean Thrasher 30 minutes later:

• • Thanks for leading the TDD charge, Uncle Bob!

  • Though I probably fall into the test-second camp in my daily work, I know the design and quality of the code I developed TDD-style is far better. I have more confidence that it does the right thing in the right way. I’ll definitely be writing more code using TDD in the future.

  • Don’t let the naysayers get to you.

Rickard Nilsson 38 minutes later:

• • MSBuild (!) was built using TDD according tohttp://weblogs.asp.net/rosherove/archive/2005/03/28/396040.aspx

Ben Rady 39 minutes later:

• • Infinitest was written using TDD.

Sijmen about 1 hour later:

• • SQLite has huge test coverage, too.

Steve C about 2 hours later:

• • Best Buy Remix http://remix.bestbuy.com/

  • Pivotal Tracker http://www.pivotaltracker.com

  • Tweed http://tweed.pivotallabs.com/

  • Treetop http://treetop.rubyforge.org/

  • Erector http://erector.rubyforge.org/userguide.html

  • Jasmine http://github.com/pivotal/jasmine

  • Jelly http://github.com/pivotal/jelly

  • ...I second sqllite, very impressive suite

Geir Hedemark about 2 hours later:

• • I can just hear the cynics already: “But what real-world, not-a-library-projects have used TDD”?

  • I worked for a smallish telco/VOIP company between 2004 and 2007. Part of my job was killing off the old perl-based backoffice solution, replacing it with something better.

  • We did it by doing a mix of TDD, BDD and integration-level testing. Defects plummeted and productivity soared after the initial six-week introduction period.

  • We also found we spent quite some time maintaining the tests when the database evolved, which was solved by creating a small set of tools.

  • Obviously, this system is not available online. Gave a presentation about this at javazone in 2007, though.

Curtis Cooley about 2 hours later:

• • The software for http://minetracer.com was written TDD, at least while I was there. I can’t account for how it’s currently written.

silentbicycle about 2 hours later:

• • Sijmen: Unit and regression testing are not the same thing as TDD. Was all of SQLite’s testing done as part of its design?

  • Most people won’t argue that having high test coverage and thorough automated testing has major benefits, particularly in the long term. Rather, people disagree with assertions about specific advantages of TDD, and whether doing so much testing upfront is always a worthwhile trade-off. Countering by taking credit for the benefits of automated testing in general is not a strong argument.

  • TDD is a means to an end. Sometimes it’s highly appropriate, sometimes it just creates the illusion of progress while obscuring ignorance of how to actually solve the problem. It would be more useful to focus on when TDD is the right tool (and when it’s counterproductive), rather than asserting that it’s always the best technique.

silentbicycle about 2 hours later:

• • Also, does it seem weird to anybody else that about half the projects listed above as TDD successes are themselves testing tools?

Josh about 2 hours later:

• • At my current place of employment we have spent the last 18 months rewriting a large portion of our externally facing application process, and the back-end admin tools. TDD throughout, with lots and lots automated acceptance testing using Fit/FitNesse

  • The result; our old websites and admin tools generate hundreds of errors a week. When we launched our new stuff (5 months after starting) it ran for almost three months before the TOTAL number of errors thrown reached double digits.

  • Changes to our old system take a lot of time to research, and a lot of time to test even for trivial things, and even then are prone to integration bugs that only manifest themselves in production. Changes to the new system tend to happen in a single sprint, and almost never causes a ripple in production.

  • I haven’t measured the actual numbers on this (although I probably should), the solution has been amazingly successful with virtually no defects.

Tierlieb about 2 hours later:

• • @silentbicyle > Sometimes it’s highly appropriate, sometimes it just > creates the illusion of progress while obscuring > ignorance of how to actually solve the problem. > In my experience, writing the test for something is the fastest way to show you understand a problem. Well, more like “how you understand a problem should be solved”, since you might still be wrong – but this way, you know.

  • And having tests is the safest way to safely adopt a new understanding of the problem, meaning: Changing to a new implementation of a solution.

  • On the other hand, the best way to obscure that you don’t understand a problem is, also in my personal experience, writing a huge API specification without any testing. This way, other implementors may go half through their implementation without seeing that you missed a crucial point.

  • Been there, done that. Yes, both. But at least the other way around.

Alexis about 3 hours later:

• • At my current place, we also tried to put Agile in place, which triggered the use of TDD.

  • Sadly, the person who was trying to push us in that direction was mostly interested in the recognition he would get by putting in place a “very cool and production way of working, and it would be so much better with it and so on”.

  • As a result, the bad developers just have the feeling that they are working correctly because “it works on their computer” (but the quality of their test is… well, crappy) and the good developers, even if they use TDD from time to time, have other way to ensure the quality of their code.

  • Naturally, I’m working in a big company, so the management doesn’t really care about who is right or not, as long as the job is done (and I believe we shouldn’t expect of them to understand the eventual quality of Agile and TDD; it’s not their job… It would be like asking me to fully comprehend medecine when I’m going to the doctor so that his job is easier). It probably emphasize the failure of Agile & TDD implementation of my company, but I suppose that it’s common in all big companies…

  • Indeed, I know that my first experience was quite bad and I can understand the use of TDD (in fact, no, I do not understand it, but I understand the eventual need of good unit test coverage in specific part of the code). But for me, it’s just a way to handle the “simple cases”; I’ve seen numerous situations were the case are hugely complex (and here the fanatics will say that it’s because the design bad and so on, but I do not really care about them anyway; it’s not like it is possible to convince them anymore…) and in then, if you wanted to make a unit test, you’d end up testing more the mocking mechanism than the code itself…

  • In the end, I’d say I use TDD about 5~10% of my time (and mostly out of my job, in small or wannabe open source projects) and unit testing for about 30% of my code (taking into account components such as web interfaces and other J2EE components).

Mike Wilson about 3 hours later:

• • The effect of TDD on my code is stellar in all the wonderful well-predicted ways.

  • In a yak shaving twist of fate, my C++ unit testing framework (release pending naming) was largely dogfood TDDed.

  • It was brutal to get used to doing things that way. But the daily “a hA!” and “wait…that all just rolls into this” I get out of it makes the old way just silly.

  • I do tend to design by coding in scratch-space. One problem with TDD is that I can’t seem to separate that “throwing paint on the wall” approach. I keep trying to test things and it gets in the way of the effort. This is a major obstacle for me actually. (Yes, I throw away anything written that way. It’s just for organizing my head.)

  • My hope is that when I get better with TDD and the accompanying toolsets (I’m using way too many languages at the moment) it won’t be such an obstacle.

  • But I’m never going back.

Paul Holser about 3 hours later:

• • JOpt Simple (http://jopt-simple.sourceforge.net) was written TDD-style.

Paul Pagel about 3 hours later:

• • For me, TDD is a form of communication with the problem.

  • It helps me put abstract thoughts and solutions into specific scenarios, keeping complex problems into small chunks that are easy to solve.

  • It provides quick feedback from the problem, allowing me to adapt my solution as I understand the problems details better. It is axiomatic the more I code a solution for a problem, the better I understand it.

David Dossot about 3 hours later:

• • After being ported from Java, NxBRE – http://nxbre.org – has been developed using TDD.

  • The extensive test suite paid for itself when the core engine went through a massive refactoring without breaking and while maintaining complete backwards compatibility.

noone@none.org about 4 hours later:

• • “Sijmen: Unit and regression testing are not the same thing as TDD. Was all of SQLite’s testing done as part of its design?”

  • well no, but it is always fun to blur the line between “having unit tests to do regression testing” and “developed test first and designed with TDD ” when arguing for TDD.

  • The SQLite example is particlularly dishonest as an example for TDD.

  • TDD , Test Driven Development not test coverage.

  • The question someone asked in the last blog was

  • “Where is the TDD equivalent of Netscape, Google Search, Fogbugz, Doom, World of Warcraft, Linux, Photoshop? Hmm?”

  • We are still waiting.

Fredrik Bertilsson about 4 hours later:

• • After following the links (that was not broken) the only availible report seem to be the 2003 study (http://collaboration.csc.ncsu.edu/laurie/Papers/TDDpaperv8.pdf). The report is extremely short (5 pages) and doesn’t give many possibilities for evaluation. After reading the report it seem to me that both groups were instructed to write automated unit tests and the difference was that the TDD group wrote the test before the implementation.

  • Are there any other studies that shows the difference between teams using automated unit tests and teams using manual tests?

Julio Santos about 4 hours later:

• • MicroPlace.com, an ebay website for helping alleviate global poverty through microfinance was built test first. I have to admit that though I do as much TDD as I can, I wish I could see examples of really game changing products/ideas/companies built thanks to TDD.

  • I blogged about it a while back:

  • http://morgane.com/2009/08/14/what-are-some-examples-of-awesome-companiesproducts-built-with-tdd/

Mike Stockdale about 4 hours later:

• • In reply to the inevitable “but what about ‘real’ line-of-business projects?”, I have participated in several LOB projects, large and small, since 2001, that have used TDD successfully and realized the benefits it claims. Because of NDA, I can’t name the projects here.

George Mauer about 4 hours later:

• • My employer is a company that leases large tanks for the storage of liquid. We have a touch screen Windows Forms application that drivers use to check in and initialize loading/unloading of their trucks. The first version of the application was extremely buggy, frequently shut down because of undetectable edge conditions and could not respond to the rapidly accumulating change requests.

  • I rewrote it ground-up using TDD while educating myself on this technique. The application has been buzzing along for months now with hardly any problems. Those that we did have 80% of the time had to do with areas that had not been tested – such as stored procedures or the UI. Overall this is the highest quality code I have ever written.

  • Using TDD also forced me into making heavy use of dependency injection. This has proved invaluable for accommodating change requests when the application’s success lead to it being deployed in other similar but quite different environments.

  • Learning TDD takes a little bit of patience but whether it is a requirement or not, all my future code will be developed tests first.

Giorgio Sironi about 4 hours later:

• • The equivalent of Google Search? Google has en entire blogdedicated to testing and TDD:http://googletesting.blogspot.com/2009/07/by-shyam-seshadri-nowadays-when-i-talk.html http://googletesting.blogspot.com/2008/09/test-first-is-fun_08.html http://googletesting.blogspot.com/2008/07/how-to-write-3v1l-untestable-code.html

Alexis about 4 hours later:

• • Thx Giorgio, didn’t know about it and the few links I tried on it seemed quite interesting…

  • I’ll read about them when I’ve a bit of time ;)

Wilkes Joiner about 4 hours later:

• • IIRC, Fit was not written TDD. The Java code did not have any unit tests. It was tested by running itself. Since it is a testing tool, that may be splitting hairs.

noone@none.org about 4 hours later:

• • “Google has en entire blog dedicated to testing and TDD: “

  • Google uses many testing practices. That doesn’t mean theydesign their software, especially using TDD.

  • Emphasis on testing != TDD. test coverage != TDD. Writing tests after code != TDD.

  • If you have any proof that the Google Search Engine (or say the BigTable infrastructure) was developed with TDD, please provide a link.

  • Or are you claiming that Sergei and larry were using TDD in their Stanford days? Or even in the early days of Google? The Google File System is now being replaced with a major new upgrade.

  • Are you claiming this was designed with TDD? Evidence?

triple-dot about 5 hours later:

• • I encourage everyone to read this blog Jacob Profitt wrote in response to the so-called TDD research.

  • http://scruffylookingcatherder.com/post/2008/01/16/TDD-Proven-Effective!-Or-is-it.aspx

  • Here’s an excerpt:

  • “Truly problematic, however, are the quality results. That’s simply a disaster if you propound “Test First” as a guarantor of quality. I mean, sure, the number of unit tests per functional unit suggests a minimum quality through increased testing, but that’s only interesting in a situation where minimum quality is important (like, for example, at NASA or in code embedded in medical equipment). The lack of any other correlation here is pretty pronounced any way you care to slice the data. Having a big clump in that upper left quadrant is troubling enough but then having the “Test Last” group almost double your “Test First” group in the over 90% quality range is something that should be noticed and highlighted.

  • While correlation doesn’t equal causation, the lack of correlation pretty much requires a lack of causation.”

  • In short, the research Phil Haack quoted in his blog is not only far from being conclusive, but also a closer look at the data suggests that the group that practiced “test last or plain old unit testing”, as opposed to “test first unit testing”, actually seems to have achieved higher quality.

  • Contrary to what Uncle Bob suggests, we HAVE done our Google searches. We just didn’t find anything conclusive.

  • Listing a majority of testing tools as proof of effectiveness of TDD in other projects really sounds like a circular argument – it should be noted that there is no shortage of projects of similar scope and scale that achieved comparable success in the non-TDD world. As noted by another poster, your attempt to blur the line between “automated unit testing” and “test driven development” is laughable. NOBODY has disputed the benefits of unit testing. What people are disputing are the alleged benefits of TDD. It seems to that if you are going to claim that “nowadays it is irresponsible for a developer to ship a line of code that he has not executed in a unit test, and one of the best ways to make sure that you have not shipped a line of code that you have not tested is to practice TDD” (), then you should be prepared to:

  • 1. Back it up with a convincing list of projects, not a bunch of testing-only projects, many of which are apparently open source and as such are not subject to many of the challenges the average developer faces in a corporate environment

  • 2. EXPLAIN why other people with impeccable hacker credentials have been able to do it again and again and again without ever practising TDD

  • () Uncle Bob said that here: http://www.infoq.com/interviews/coplien-martin-tdd . The way Uncle Bob was unable to rebut Jim’s criticism against TDD in that debate is rather telling.

Uncle Bob about 5 hours later:

• bq. Wilkes Joiner about 4 hours later:

  • IIRC, Fit was not written TDD. The Java code did not have any unit tests. It was tested by running itself. Since it is a testing tool, that may be splitting hairs.

  • I saw very early versions of Fit source code, and there were certainly unit tests for it. Were they written first? I don’t know.

noone@none.org about 5 hours later:

• • “Uncle Bob said that here:http://www.infoq.com/interviews/coplien-martin-tdd . The way Uncle Bob was unable to rebut Jim’s criticism against TDD in that debate is rather telling.”

  • The infoq discussion is very revealing.

  • I guess Jim Coplien is a "deranged"  "stone age programmer" too? ;-)

Uncle Bob about 5 hours later:

• • What I_ want to know is which camp are the democrats, and which are the republicans. Perhaps you think this isn’t a political debate, but the _sneering is certainly the same.

noone@none.org about 5 hours later:

• • “but the _sneering is certainly the same.”

  • Oh poor you Uncle Bob.

  • I wonder who started all this nastiness by calling other programmers (who  don't share your ideology) nasty names - like "unprofessional"  "stone age", "deranged"?

  • Oh btw you still don’t have any answers . No great codebase . No worldchanging products. Flawed research. Fudged lines between “tests” “test coverage” “unit tests” and “tdd”.

non about 5 hours later:

• • Hmm a weird formatting error trying again.

  • Uncle Bob said, “but the _sneering is certainly the same.”

  • Oh poor you Uncle Bob.I wonder who started all this nastiness by calling other programmers (who don’t share your ideology) nasty names – like “unprofessional” “stone age”, “deranged”?

  • Oh btw you still don’t have any answers . No great codebase . No worldchanging products. Flawed research. Fudged lines between “tests” “test coverage” “unit tests” and “tdd”.

Joe Mathes about 5 hours later:

• • IMVU uses TDD very heavily, and on a huge code base

Jean-Yves about 6 hours later:

• • Here http://nemo.sonarsource.org/ you can have a look at some open source projects / code metrics, does not means it is TDD, tough 80% or more unit test coverage is often a TDD symptom.

Eddy Young about 6 hours later:

• • DataNucleus (formerly JPOX), a JDO implementation.

asdf about 6 hours later:

• • There’s a whole lot of “this code base uses lots of tests” being equated to “TDD is good”. Testing is good, TDD is just another religion for hacks to sell books and conferences on.

Rick T about 6 hours later:

• • http://www.yafla.com/dforbes/The_Underappreciated_Art_of_Duct_Tape_Programming/

  • Just finished reading that before being linked here, and found it fascinating in the mix of the conversation.

  • Thanks for the perspective, Bob

MrDustpan about 7 hours later:

• • Curious to know if the TDD detractors have tried TDD and found it ineffective, or if they just don’t like the concept.

Andrew about 7 hours later:

• • I’m kind of TDD agnostic having tried with and without it

  • I think its important to write unit tests for the bits of code that do something complicated

  • Code that you write once and get right first time because its so simple doesn’t necessarily deserve a test, even when maintenance is taken into account

  • In short, like pretty much all programming bun-fights, there is no need to be dogmatic

maksa about 7 hours later:

• • From what I’ve heard – Eclipse is written using TDD.

noone@none.org about 8 hours later:

• • “From what I’ve heard – Eclipse is written using TDD.”

  • No it is not.

  • Sigh! again , presence of unit tests != TDD.

  • The Eclipse Development Process makes no mention of TDD. If you have other sources of info please provide references.

nooneelse@none.org about 9 hours later:

• • Pot, meet kettle.

  • Uncle Bob said - “rude, insulting, derisive, dismissive, and immature”.

  • Like referring to Barack Obama as ‘BO’ as you have done more than once in your tweets, “Uncle” Bob?

  • And there was that tweet about him having “earned’ his initials” as well.

  • Classy, very classy…

Carlos Peix about 9 hours later:

• • NHibernate: http://nhforge.org/

James about 9 hours later:

• • How do you manage to write Junit using TDD? Using public static void main() for all tests?

  • Just because there are unit tests for an application does not mean that it is done using TDD.

  • Unit testings and testings in general exist a long time before the invention of TDD.

  • I know that this isn’t wikipedia, but can you provide any source to ANYTHING that you claimed to be done using TDD?

Ryan about 9 hours later:

• • While you’re at it why don’t you add this piece to your list of TDD researches?

  • http://theruntime.com/blogs/jacob/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx

maksa about 9 hours later:

• • Hey Uncle Bob, why don’t you also post the subsequent critique of your first link?

  • http://www.theruntime.com/blogs/jacob/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx

Philip Schwarz about 9 hours later:

• • @James

  • You said: How do you manage to write Junit using TDD?...I know that this isn’t wikipedia, but can you provide any source to ANYTHING that you claimed to be done using TDD?

  • In this blog entry, Kent Beck, one of the authors of JUnit, said:

  • Working on JUnit, the whole bag of XP practices makes sense. We always test-drive development. We refactor whenever we can, sometimes trying 3-4 approaches before hitting one we are willing to live with.

Philip Schwarz about 9 hours later:

• • @James

  • You said: How do you manage to write Junit using TDD?

  • My guess is that you use some form of boostrapping.

James about 10 hours later:

• • @Philip Schwarz

  • I think you missed this bit.

  • “When I started Max I didn’t have any automated tests for the first month. I did all of my testing manually. After I got the first few subscribers I went back and wrote tests for the existing functionality.”

James about 10 hours later:

• • TDD Proven Effective! Or is it?

  • http://www.theruntime.com/blogs/jacob/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx

James about 10 hours later:

• • It seems that Uncle Bob is censoring messages that mention the critique of his first link study by Jacob Proffitt.

  • If you want to read it, use google and search for “TDD Proven Effective! Or is it?”

noone@none.org about 10 hours later:

• • “It seems that Uncle Bob is censoring messages that mention the critique of his first link study by Jacob Proffitt.”

  • I doubt it. As of now it is very visible in a message by triple-dot above. I think he is completely deluded in his fixation on TDD and denigration of programmers who don’t use it, but give the man his due. He doesn’t censor critical comments (afaik) and has the guts to face his detractors.

Grok2 about 10 hours later:

• • I would like real-world examples of projects done by large teams that used TDD. It’s simply point-of-view when a single person or a small team (3-4 cohesive members) say they used TDD for a product or web-site, but it really proves the point if there is a real-world example of a large team using TDD successfully.

Philip Schwarz about 11 hours later:

• • @asdf You said: TDD is just another religion for hacks to sell books and conferences on

  • From JB Rainsberger, one of the leading members of the TDD community:

  • It surprises me, from time to time, how much I still need to justify test-driven development to prospects and would-be course attendees. Many feel that TDD has crossed the chasm, while others still see TDD as a cultish practice worth marginalizing. I take some blame for those who find TDD cultish, because until now I haven’t had a strong, sensible, theoretical basis to justify TDD as an idea. I could do no better than “it works for me” or “my friends like it”. That has changed…

  • If you buy in to ideas from Theory of Constraints or Lean Manufacturing, then I think I now have a stronger argument to justify the core programming practices in extreme programming in particular and agile software development in general. I don’t even need all of the Theory of Constraints but rather a simple appeal to fundamental concepts in Queuing Theory.

  • Read the full post, which includes the following take-home point:

  • Where test-first programming helps most teams most of the time reduce their mistake count to near zero, test-driven development helps them reduce their design inventory—mostly code that gets in our way because it doesn’t actively help us deliver a feature—to near zero. This further increases productivity and improves their ability to deliver by helping them waste less time agonizing over design problems they find costly to fix.

Philip Schwarz about 11 hours later:

• • @Geir Hedemark

  • You said: I can just hear the cynics already: “But what real-world, not-a-library-projects have used TDD”?

• Is the following, from Misconceptions with Test Driven Development, part of the problem?:

  • So if TDD can be used on a large scale and to help drive architecture there must be examples. The leading members of the community (JB Rainsberger, Nat Pryce and Lasse Koskela) all have clients with products built and architected using TDD. Unfortunately these are all closed source or clients that don’t want to be talked about publicly.

Philip Schwarz about 11 hours later:

• • @James

  • You said: I think you missed this bit:“When I started Max I didn’t have any automated tests for the first month. I did all of my testing manually. After I got the first few subscribers I went back and wrote tests for the existing functionality.”

  • I did not: Junit and Junit Max are two different products. Re-read Beck’s post to see how the different natures of the two products justify using TDD for one, but not for the other.

James about 11 hours later:

• • @Philip Schwarz

  • The article you linked to makes no sense. It work on a flaw logic of: C works for A, B resembles A therefore C should work for B as well. C in this case is the logic for Queuing Theory, A is the Queuing Theory and B is TDD. The author basically saying that since TDD looks similar to the process described by Queuing Theory, therefore the logic of Queuing Theory must validate TDD.

  • The important parts of the statement missed by author is highlighted by me.

  • “Given a process B, which follows a process A, sometimes in performing B we need to perform some of A again. We can remove the need to rework by taking some portion of process B and performing it before process A1.”

  • Here’s my observation:

  • 1. Test is code. Since code is testing code it doesn’t matter what occurs before or after. 2. writing only the code we need should be a given. The only time when you’re not doing that is when you’re hacking and have no idea what you are doing. 3. Test first only works if you can assert against a known solution. Working out the 1000th largest prime does not have a known solution at the start. 4. Short cycles is not exclusive to TDD. 5. Imagine a list of requirements [1,2,3,4, ... n]. TDD start with the first requirement and works it way through. There is a high chance of reaching a requirement j (1 < j < n) that would obsolete the requirements before it. TDD would produce wasteful code if the programmer didn’t look at the big picture.

Tim Andersen about 14 hours later:

• • I like TDD for the following reasons:

    1. I’m going to have to test the code I write anyway, and I’m motivated to avoid manual work so I might as well automate it. Besides, I like writing code (writing tests is writing code).

    2. I’ll know when I’m done. Then I’ll have a chance to go back and use hindsight to simplify my code.

    3. I’m addicted to the thrill of passing tests (green bar!)

    4. I’d rather write code than documentation or javadocs

    5. I’d rather work on new features, not being stuck in a debugger fixing things I broke because I didn’t have tests.

    6. My tests are canned thoughts that I can bottle up and then open up all at once without using brain cycles for thinking through the contexts and complexities I have already thought about. While my tests run, I can think about the next steps or go get a coffee and feel like I’m still being productive.

    7. TDD helps me eliminate waste by catching defects before I have even written them.

    8. Better design decisions: TDD helps me keep code clean, simple and loosely coupled. Lately I have been back-filling missing tests on a legacy code base and I am feeling the pain of writing tests for code that was not written with TDD, and is very hard to test. Because of this, writing the tests takes a lot longer. It would have been much easier to write the tests if they were test-driven in the first place (we have experienced this because there are parts of the system in which we reimplemented with code that was written using TDD)

James about 14 hours later:

• • > I’m going to have to test the code I write anyway, and I’m motivated to avoid manual work so I might as well automate it. Besides, I like writing code (writing tests is writing code).

  • Doesn’t really say much about test first or last. Writting code for the sake of writting code is wasting the client’s time if it can be avoided. This include writting duplicate test cases that test the same functionality in different places.

  • > I’ll know when I’m done. Then I’ll have a chance to go back and use hindsight to simplify my code.

  • If you have to go back and simplify your coee, then you’re not done. You might have a functionally correct implementation but a poor one that might not meet the system qualities (non-functional requirements.) You know when you can visibly see your code working through your portotypes. Testing first is not a neccesary indicator.

  • > I’m addicted to the thrill of passing tests (green bar!)

  • Even false positives? If you have a psychological need to see green bars then TDD might help you.

  • > I’d rather write code than documentation or javadocs

  • This sounds like hacking to me. It is easier to look through diagrams than to look through 100 test cases to immediately know what your code is supposed to do and the relationships between your objects. Furthermore, have you used a library that is poorly documented? Imagine another team is using your component. It’s unprofessional unless you work in a small close-nit team

  • > I’d rather work on new features, not being stuck in a debugger fixing things I broke because I didn’t have tests.

  • Didn’t really have anything to do with TDD

  • > My tests are canned thoughts that I can bottle up and then open up all at once without using brain cycles for thinking through the contexts and complexities I have already thought about. While my tests run, I can think about the next steps or go get a coffee and feel like I’m still being productive.

  • Sounds to me like you have problem articulating ideas and thoughts without touching the keyboard. In addition, you’re using tests as a procrastination to doing the actual thinking.

  • > TDD helps me eliminate waste by catching defects before I have even written them.

  • This doesn’t make sense. Code testing code. If you have bad tests then even with good code, it would still fail sending you on a wild goose chase. This happens to me before. Why do trust your test code more than you trust your production code?

  • > Better design decisions: TDD helps me keep code clean, simple and loosely coupled.

  • No it doesn’t. Experience and knowledge in design will help you keep your code clean and loosely couple. If you lack these skills you’re just gonna stuck with bad tests and bad code.

  • > Lately I have been back-filling missing tests on a legacy code base and I am feeling the pain of writing tests for code that was not written with TDD, and is very hard to test. Because of this, writing the tests takes a lot longer. It would have been much easier to write the tests if they were test-driven in the first place (we have experienced this because there are parts of the system in which we reimplemented with code that was written using TDD)

  • It’s hard to test because it was designed badly, not because it wasn’t done using TDD. I’ve seen teams who did TDD and ends up writing tests for their tests.

Jens about 17 hours later:

• • Though being quite positive towards TDD I have severe doubts in the results of many of the experiments.

  • In Karlsruhe, Germany, there was a quasi-experiment showing that TDD research results from experiments with students are not really generalisable to a population of professional developers.http://www.ipd.uka.de/Tichy/uploads/publikationen/136/MuellerHoefer2007.pdf

Wedge about 19 hours later:

• • TDD proponents often come off as arrogant, dogmatic cultists, which I think explains much of the strength of the backlash against TDD.

  • TDD likely has very real benefits, but even so it is no silver bullet, nor is it a panacea for every software development malady. Pragmatists recognize that different tools and different methodologies are needed in different situations, and over-engineering can be just as dangerous as under-engineering (a carbon-fiber toilet is just as dumb as a construction crane made of toothpicks and glue).

  • More so, when experienced developers who have long histories of putting out successful, profitable, useful software hear the message that it’s not possible to be a serious software engineer without practicing TDD or that every single software project on Earth should be using TDD they may get a little defensive. Or perhaps more than a little. Indeed, they may mentally put the TDD proponents into the bozo bin.

  • Again, TDD likely has very real benefits, but those benefits are incremental, and they are not necessarily realized on every software project (few methodologies are). Once TDDers begin to see the world as something other than a universe of nails, then perhaps TDD detractors will have less to complain about, and pragmatists may start taking TDD more seriously.

Esko Luontola about 19 hours later:

• • Miško Hevery posted recently his measurements about how much of his time is taken by writing tests. The magic number is about 10%. A big reason is that the test code is always very simple compared to the production code – no conditionals, no loops. Just a couple of method calls and assertions linearly. He also goes to outline the benefits, which make the extra 10% well worth it.

  • http://googletesting.blogspot.com/2009/10/cost-of-testing.html

Steve Seymour about 24 hours later:

• • Oh my God, Uncle Bob. Are you still trying to convince the world that TDD is a wonderful technique that all disciplined, professional software engineers should follow? And are there still legions of people arguing against this? And does everyone belonging to these legions not have the dedication, perseverance, and professionalism to actually commit themselves to TDD for an acceptable period of time before judging it honestly? Would these people rather play with TDD for a few hours or maybe, just maybe, a few days, and then throw it away (like I did during my first exposure to it, though I did it with the idea of returning to it someday, thankfully which I did) and form an inexperienced opinion of it?

  • I know, I know, you’re in a position of leadership and you are trying desperately to right the ship of the sad software world, a world severely lacking professionalism. But, I can’t help but wonder how much time, energy, and emotion you sink into this debate that is long over for anyone that has sincerely practiced TDD, and what other things you could be doing with your passion. Why not just let those that argue against it go and reserve your time (and mine, for responding to this post) for better things?

  • And yup, I’m a TDD snob: Anyone not regularly practicing TDD is not a professional developer, and anyone practicing it is. Those that practice it aren’t necessarily great developers, but they are at least professional in their approach. And I must say that some who don’t practice TDD are great developers, but clearly they could be better if they TDDed.

  • It really is that simple. Anyone that has seriously undertaken the TDD craft knows it, and anyone else doesn’t have the right to voice an opinion.

  • Please, Uncle Bob, go back to writing down thoughts concerning something else. You are a wonderful writer with often profound thoughts that I very much enjoy reading. Let the lazies go back to their work. Some of them are good developers and most are not, and there is enough written on this topic (by you alone!) to initiate at least a portion of them to try TDD and to realize its vast benefits.

  • And don’t give too much credit to Joel in order to soften your chastising of him: his original post wasn’t that good.

Rick T 1 day later:

• • TDD is much more obvious, and easy to accomplish with clarity and focus, for those projects that are simply a rewriting of existing code in a different language. The tests are self-evident, as is the destination.

  • That is the problem with TDD. While it is an obvious win for trivial tasks, for less-trivial, less-obvious tasks the merits are much less obvious. I can’t write a TDD suite before coding when I’m not entirely sure what I’ll be coding.

  • I guess my point is that if you’re working at an outsourcing sweatshop and the client says “take A and B and sum them to C”, the advantages and route to TDD is self-evident. If that isn’t your genre, it’s much more fuzzy. So when someone gives some claim that TDD is what “professional” developers do, they’re really betraying the simplicity of their task.

Chuck van der Linden 1 day later:

• • >>I can’t write a TDD suite before coding when I’m not entirely sure what I’ll be coding.

  • If you’re not entirely sure what you’ll be coding, you don’t understand the problem you’re trying to solve, or how what you are about to create is supposed to behave.

  • I would argue that in such a situation is is even MORE important to write the tests first as it forces you to gain a better understanding of what you are trying to create. Of how what you are about to build is supposed to behave, and how you know it’s working correctly or not. How you know you are done.

  • That’s a major part of TDD, it’s not just the writing of the tests, it’s that in order to write the tests you have to get yourself to a point that you a good enough understanding of what you’re supposed to be building that you CAN write the tests. It makes you better define the problem space.

  • If you run off and start coding before you know what you’re doing, how do you know you’ve written the right code? how do you avoid ending up writing a bunch of stuff that doesn’t matter? sure you could get lucky and fall into none of those traps, but having the test there first makes that a lot less likely.

  • Another value of writing the test first btw is you can watch it fail. and knowing the test fails without the code working has value all it’s own and is difficult to do after the fact. That in itself tends to create better quality unit tests that are less likely to fail to detect problems if they occur.

  • (although I’ve heard of some cool tools that make changes to the code and then report if tests don’t fail as a result, which no matter if you are doing tdd or not, is a great concept for making sure you have good tests)

Philip Schwarz 1 day later:

• • @Steve Seymour

  • You said:

  • Oh my God, Uncle Bob. Are you still trying to convince the world that TDD is a wonderful technique that all disciplined, professional software engineers should follow? And are there still legions of people arguing against this?

  • These battles last decades! Less than a month ago, in this interview, Kent Beck, the father of TDD, said:

  • every idea that I have had that has taken off has taken 20 years, at least, so, TDD at this point is close to that old, and I would say that it is pretty much on track with the other things that I have done ... 

  • and TDD seems to be like the second thing [after continuous integration] that is going to have some impact

Stephane 4 days later:

• • Moq, one of the major Mocking framework in .NET has been written with TDD the whole way according to his author in this article. But I never checked the code myself :)

  • http://www.clariusconsulting.net/blogs/kzu/archive/2009/09/29/AreyousmartenoughtodowithoutTDD.aspx

Joseph Beckenbach 5 days later:

• • Another app suite using TDD (as part of 18 months of small-team dials-to-11 Extreme Programming joy-ride): Eidogen’s TIP. (bioinformatics)

  • As of my last involvement, April 2005: 250K lines of Java, all TDD by 350K lines of unit test code. 100% coverage by team fiat, only two defects (both cosmetic) shipped to customers, with some millions in revenues earned. (The 18 months before XP and TDD had far less code and few tests of any sort, with nothing released and no revenue.)

  • In early 2005, we solved the SARS virus, ready to find drug candidates in silico, six months before the crystallographers. TDD made that capability happen.

NotherBob 5 days later:

• • Don’t know what/when Kent said it, but this was the punch line of a story that went around before Kent was born. Here’s the version I remember:

  • It seems a team of developers had implemented a complex set of business rules but their code was full of bugs and kept crashing. So another developer reimplemented the rules as a table-driven process. When he presented it to the team, the leader said, “But ours is implemented in straight-line code. Your table-driven code will be a lot slower.” The developer replied, “But mine works.” They went back and forth like this for a few rounds, until the developer finally said, “Hey, if it doesn’t have to work, I can make mine as fast as you want.”

  • You’ve repurposed the joke to apply to development time. Still works.

tieTYT 8 days later:

• • Uncle Bob: I wish you’d respond to the comment @triple-dot made (or at least the article he linked to). I think it was the most interesting comment in this whole thread.