are working on a talk reviewing what must be about 10 years of TestDrivenDevelopment
. What do you think were the significant moments in its history? Here are a few strawman moments to get started with. I'm sure there are more, and that there's some interesting pre-history.
- 12000 BC : OgTheVenerable?, holding a raw piece of meat, describes the process of creating fire to his fellow cavemen, setting their expectations and a prescription for his own task. The piece of charred meat he held in his hand afterward is widely regarded as the first passing test case.
- 1815-12-10 to 1852-11-27 : AdaCountessOfLovelace? creates the need for computational TDD unawares: "She used the information and formulas supplied by Babbage and determined where the calculations would go into the machine and where the answers would be displayed. Since Lovelace had no machine on which to test the program, printed editions of her "Notes" available today contain some errors." -- http://www.bookrags.com/research/lovelace-ada-byron-king-countess-of-csci-01/
- 1959 through 1963 : programmers for the Mercury Space Program use a form of TDD while programming punched cards
- 2009-01 : JoshuaKerievsky declares Brian Marick to be misinformed (in bed with his laptop, Jan 2009)
- AlanFrancis shouts at Brian and Josh "You kids play nice! Don't make me come in there !"
All fun aside, what I said was "In sum: compared to doing exploratory testing and TDD right, the testing we’re talking about has modest value. Right now, the cost is more than modest, to the point where I question whether a lot of projects are really getting adequate ROI. I see projects pouring resources into functional testing not because they really value it but more because they know they should
value it." My workshop position paper: http://www.exampler.com/blog/2008/07/09/position-statement-for-functional-testing-tools-workshop/
"Question" is not the same thing as "declares". I'd be happy to see this reverted, Josh. -- BrianMarick
Hi Brian. I'll have to read your report. In my experience, it is as easy to mess up TestDrivenDevelopment
(TDD) as it is StorytestDrivenDevelopment
(SDD). Also, I've definitely learned that some work on User Stories proceeds better from straight TDD and some does better from SDD. In the past year (2008), I've found that SDD is way way better when we use a normal programming language and endeavor to make our automated storytests human-readable, rather than wasting tons of time on fancy tools or languages.
Also, there are two parts to this stuff -- Storytesting and StorytestDrivenDevelopment
. Storytesting is simply coming up with acceptance criteria for stories -- it can be done on a card, a whiteboard, a document, etc. SDD is about automating the storytest first, before any other programming begins. I know that Storytesting hasn't failed -- it is an excellent way to communicate between customers and developers. I do know that some folks (including myself) have gone down some dead ends with respect to how they practice SDD, yet the value I've seen from it is there and has helped us push further into an efficient practice of SDD.
My only regret is that we haven't adequately articulated the art of SDD. That's partly because we're still learning quite a bit! Hopefully we'll produce something on this soon. --JoshuaKerievsky
If you want all the details on my cost/benefit rough-guess, see http://www.exampler.com/blog/2008/03/23/an-alternative-to-business-facing-tdd/
I mention this because the short blurb I linked to might make it seem I'm down on storytesting, which I most definitely am not. What I question is the value of going from the whiteboard discussion to automated execution. -- BrianMarick