Unit Testing, Agile Development, Architecture, Team System & .NET - By Roy Osherove
Ads Via DevMavens
Great post. I would have loved to hear the "boxing match" between you and Jim. I let out an observable sigh every time I hear nonsense such as "TDD will deteriorate your architecture." Such words are always said by someone that hasn't done the work to learn TDD.
A great conference, indeed! I have written some notes about the TDD controversy here:
community.ative.dk/.../the-tdd-controversy-jaoo-2007.aspx
That's unfortunate, after this discussion to get such a conclusion. I've been there, and I thought you were convinced with the fact that Test Driven Development is a misleading term. And I thought that you agreed that there is nothing driven by the test. Rather you drive the tests! Just I find it a pity that you are telling half of the story. And that you are concluding by "don't listen to Coplien" after all the arguments he had!
Anyhow, I guess I’ll extend my blog post <a href='sadekdrobi.com/.../i-always-write-tests-before-code-but-i-don%e2%80%99t-do-test-driven-development'>I always write tests before code, but I don’t do Test Driven Development</a> to talk about this very discussion, and an excellent metaphor Jim mentioned.
Anyways, fortunately, and with the help of Floyd (InfoQ's Co-founder) I could arrange a debate with James Coplien and Bob Martin about this very topic. I guess it will appear at InfoQ sometime soon. And it is up to you to judge. There you'll get the full story, and you’ll know why I got upset reading "just don't listen to Jim"...
Sadek: It was meant as a half ironic remark.
as I said I have a full blog post on this subject that has a more "balanced" look.
In the meantime, I do mean it to say "don't listen to him until you get the full picture"
well ok, now i prefer this one "don't listen to him until you get the full picture"
Hi, Roy,
Just to help out your readership, and continuing in the rich vein of half-ironic remarks:
If they shouldn't listen to me, then who _should_ they listen to (I mean, besides you)?
Is there anyone else that we shouldn't listen to? I take it that your filtering criteria are along the lines of agreement with your position rather than on the basis of any rhetorical or dialectic principles?
There is only one case in which I advise people to not listen to someone: when they attempt censure. Let me then take this rare opportunity to exhort people to ignore your censure and to grab every perspective they can with both hands. The evidence for TDD is shaky and the evidence against it is growing (as in the two research papers I related at JaOO). We need industry dialog on this and I think that many have something to offer — even those whose objectivity we might call into question because they have a vested interest relating to their stake in writing a book on a related topic or something.
My position comes not from a vested interest but from broad experience applying TDD in software all the way back to the late 1980s at Bell Labs, and in hardware all the way back to the 1990s in Bell Labs and in a company called DAFCA (I'm not making this up) whose raison d'être can be viewed as supporting designers to do TDD-for-hardware.
So I won't be so foolish to say that to get the full picture, you should listen to me, but I do feel I have part of the picture. Like you, I'm willing to put my cards on the table. I'll let the reader judge the results for themselves, and prefer that to having someone else judge for them.
Tell you what: let's start getting that Agile conference together and let's bring some people together to sort this out in workshops, panels, and the like. I think it could be fun, and it would be good to pick up where we left off — and, as Sadek points out, to get to the other half of the story that seems to have vanished from your post.
Now that I'm having some real time to write something I thought I'd try to write down my thoughts starting
So far, I like the title :-) Go for it!
Hi,
Thought you'd like this photo from the hall debate: www.flickr.com/.../1438966887
:)