TDD Extremism
Posted March 3, 2008 
Comments(3)
Comments(3) Cedric Beust has written a well considered counter to TDD extremism. He is right in that TDD can seem compelling when writing simple class structures, but that it can become a hindrance when coding more complex cases. The argument to that, of course, is that TDD will help refine your API and integration points, but I think the point really is that it’s perfectly possible to have an elegant interface without TDD. As Cedric says, TDD should be considered simply one of an array of tools.
Cedric’s “rules of thumb” are good:
- “Tests first” or “tests last” is unimportant as long as there are tests.
- Try to think about testing as early as possible in your development process.
- Don’t let one liners contradict your experience. For example, don’t listen to people who tell you to write “the simplest possible thing that could possibly work”, also known as YAGNI. If your experience tells you you’re going to need this extra class in the future even if it’s not needed right now, follow your judgment and add it now.
- Keep in mind that functional tests are the only tests that really matter to your users. Unit tests are just a convenience for you, the developer. A luxury. If you have time to write unit tests, great: they will save you time down the road when you need to track bugs. But if you don’t, make sure that your functional tests cover what your users expect from your product.
- Don’t feel bad if you are not doing Test-Driven Development. There are a lot of factors that make this practice a bad fit for a lot of projects and developer personalities (aspects which are very often never mentioned by TDD extremists).
I’m not at all against TDD, and indeed, I use RSpec with Rails consistently before coding implementations, but the point is let’s not get fanatical about this. It’s not a cure-all.
What makes you think that Cedric’s “rules of thumb” are good? You’ve made a value statement without supporting it. Here, I’ll support why I think Cedric’s “rules of thumb” are an indication that he doesn’t understand how to do TDD. Well, except for bullet 2. I love bullet two! I also don’t understand this talk about fanaticism or extremism. Your comparing software developers (who are trying to get people in alignment on good engineering practices) with people who strap bombs to their chests and blow up cafes. I’m pretty sure that isn’t what is happening.
******
I find bullet 1 incorrect because you will develop more tests if you write them first. Perform some TDD by pairing with a good practitioner and I know you will agree.
Bullet 2 is a good one! In fact, it contradicts bullet 1 and supports why Cedric should write his test first.
Bullet 3 about YAGNI is a very useful tool for preventing people from spiraling to complexity. People who don’t like YAGNI probably don’t like working with someone who says they’re design is more complex than necessary.
Bullet 4 isn’t on the mark. The only thing that matters to your users is that the application is useful. This also argues that the application is of sufficient quality to be useful. Unit testing as well as functional testing are ways to achieve this quality. Unit testing will scale to far more code coverage than functional testing. So unit testing is very important too.
Bullet 5 — You should feel bad if you are developing low quality code. Don’t worry, you’ll still find places that figure if you can write code, you can make quality someone else’s problem. If you practice TDD, you are addressing quality as soon as possible. You are also doing testing as soon as possible (bullet 2, remember). As far as the comment about where TDD is a bad fit, there aren’t many…. TDD is harder to do in some circumstances than others. The biggest circumstance is where an architect/developer is trying to make something more complicated than it has to be, or they are mixing concerns by writing super big methods, or they are coupling their code to other classes instead of writing nicely decoupled code. Yes, TDD forces you to architect better and some people don’t like to do that. They’d rather do it their way and throw the code over the wall to someone else.
Another common misconception is that TDD means writing a slew of tests first. This is a violation of YAGNI. You write the simplist test first, then write the simplist piece of code to make it pass, then start back writing a new simplest test. About three tests in, you have some pretty sophisticated code. You keep at it, and after a while, you are done.
Lance Kind
Practicing TDD since 1999
I think you’ve misconstrued what I said. When I talk about TDD Extremism in the context of Cedric’s post, it is specifically with this line of his in mind: “the notorious TDD extremist who thinks that every software developer who doesn’t TDD every single line of code she writes is unprofessional”.
Neither of us is complaining about TDD in general. I use it every single day, and Cedric (as creator of TestNG) is a proponent of it to a certain extent as well.
So a typical practitioner is not in question. But a TDD practitioner who refuses to believe that good quality, useable systems can be created without TDD at the core is being suggested to be extreme, and I wholeheartedly defend that point of view.
Your rebuttal of Cedric’s bullet points miss the mark completely:
* You say that you will develop more tests if you write them first. True in some cases, not true in others.
* You say bullet 2 contradicts bullet 1… although it doesn’t. Thinking about testing doesn’t require tests up front.
* You say YAGNI helps spiraling into complexity. Fine. But Cedric is saying that sometimes, You ARE Going To Need It, and it can make life more difficult to go with the simplest thing first.
* You say that the only thing that matters to users is that the application is useful. Agreed. What Cedric is saying is that quality is really your problem. If there are bugs because you’ve built with insufficient quality, then it is your problem. The user isn’t going to fix your bugs. They will keep sending it back to you till their functional tests pass. Do they care if you use unit tests or not? No. Of course it’s probably easier if you have, but that is not their concern. And if you write something that passes their functional tests (but doesn’t have unit tests), they will be happy and the world will go on.
* You say: “You should feel bad if you are developing low quality code. Don’t worry, you’ll still find places that figure if you can write code, you can make quality someone else’s problem.”, which is just FUD. Quality and writing your tests first are not the same thing. Get a grip.
You haven’t explained why tests have to be written first at all.
Again, to be clear, I develop test first almost all of the time. But I am vehemently against the idea that it is the only way of writing useful software.
This post by Martin Fowler touches on why I think it is unreasonable for “TDD Extremists” to claim there is only one right way to develop software:
http://martinfowler.com/bliki/SchoolsOfSoftwareDevelopment.html
To be clear, again, I like TDD, and I use TDD consistently and often, but not always. Which seems sensible and valid, and I certainly wouldn’t try and force someone else to use my method of development.