The various meanings of TDD
Update: more on this here and here, and Jim has a whole article on this here.
Now that I'm having some real time to write something I thought I'd try to write down my thoughts starting all the way back from JAOO and what I learned from it. Specifically the whole notion of TDD, and what does TDD mean to different people.
"TDD will deteriorate your design". that was the sentence I heard coming out from the mouth of Jim Coplien, a speaker at JAOO and a well respected guru in the software industry in many levels. I tried to grasp what he was saying again, so I repeated the sentence in my head. "TDD will deteriorate your design, so don't do it". Yes. I heard correctly.
It was lined throughout the discussion Jim was having about Scrum and Architecture and was just one small point he made which he didn't even take the time to review fully. "Will deteriorate your design" and then nothing. Someone from the crowd of about 400 challenged him and Jim was starting to quote a couple of research papers which I don't have a link to so I have not read them. Jim was kind enough to leave a comment on my previous post about JAOO but that did not include any links to those research papers. Could anyone leave a comment here with a link to them?
When Jim walked out of the hall I started talking to him for what ended up to be about 40 minutes of intense rhetorical debate of what does TDD really mean and then what benefit if at all does it have. I'll weave points from that in but first I need to say that I realized something: TDD is not a clear enough concept so people see it in different light depending on who you ask.
What are the possible meanings of TDD?
- 1) Test Driven Development: the idea of writing your code in a test first manner. You may already have an existing design in place.
- 2) Test Oriented Development: Having unit tests of integration tests in your code and write them out either before or after our write the code. Your code has lots of tests. You recognize the value of tests but you don't necessarily write them before you write the code. Design probably exists before you write the code
- 3) Test Driven Design(the eXtreme Programming way): The idea of using a test-first approach as a fully fledged design technique, where tests are a bonus but the idea is to drive full design from little to no design whatsoever. You design as you go.
- 4) Test Driven Development and Design: using the test-first technique to drive new code and changes, while also allowing it to change and evolve your design as an added bonus. You may already have some design in place before starting to code, but it could very well change because the tests point out various smells.
It's important to realize the distinction between these four perceived notions of what TDD could mean because when Jim said "don't do TDD" he meant one of these. Unfortunately he didn't really explain which one he meant (maybe he hadn't realized they exist) so the message he gave out was essentially "Whatever you think TDD is, don't do it".
Which of these notions corresponds to what you think TDD is? which do you think I would choose?
From my conversations with Jim it would seem that he think about TDD as option number 3 - Test Driven Design. He was saying that if you do it the XP was where you let the tests drive all of your architecture you're bound to get into trouble so leave it alone. I'm leaving the argument of whether pure test driven design works or not for later. Right now I want to make sure we're all on the same line.
If you're going to say TDD doesn't work - explain what you mean by TDD or be prepared to be bombarded with questions which you may feel have no connection with what you're talking about.
My notion of TDD is #4 - Test Driven development which can also help evolve and better your design. I always start with some sort of design, even a basic one. Sometimes so basic it's all in my head or on a whiteboard, but there's some skeleton there I use to guide me. I also let it change if my tests point out that there might be some testability problem here and there. I'm not saying pure Test Driven Design does not work. I'm sure it works for people, and I'm sure if failed others.
The Alpha Architect and Test Driven Design
One interesting thing that came up in that conversation (which many people assembled and chipped in with their on thoughts in) was the idea of the "Alpha Architect". There seemed to be agreement that the people who can do pure test driven design (like Ron Jefferies) probably already hold all the design they need in their head, so they don't get why other people can't do the same thing. These "Alpha Architects" are pretty unique and perhaps live in some sort of bubble where things like TDDesign feel much easier and simpler. I'm not sure that's the case but I can understand the idea and willing to agree that it's possible.
So, is Test Driven Design only good for teams with Alpha Architects in them? not sure, but it's a question worth asking.
So, is TDD Bad?
Are the rest of the notions of TDD bad? In our talks Jim agreed that unit tests or integration tests might not be a bad idea after all as long as they don't kill your design. When he said "but I was saying TDD kills design I said it because that's what people think TDD is!". The only reply to that is that by telling them that you are only reinforcing their belief that they know what TDD is, and not even questioning their assumption (or yours) that it could be a good thing.
I think that TDDAD(Development and Design) is a good thing. I'd love for my assumptions to be challenged. I'm still waiting to get the links to the two research articles mentioned.
your comments are appreciated.
possible topics for the future posts:
- Things I realized about XUnit from talking to Brad and Jim
- BDD vagueness and tooling
- Ruby coolness
- The ALT.NET Conference roundup