Scruffy Looking Cat Herder (aka Jacob Proffitt) recently wrote Test Driven Development considered harmful. Jacob is writing about why he believes that TDD zealots have caused people to skip unit testing altogether. I allege that Jacob is missing the boat here.
The gist of Jacob’s hypothesis has five points which I summarize:
- Unit testing provides benefits when used regularly.
- Ensuring that developers write unit tests is the prime benefit of test driven development.
- Most unit test advocates are also TDD proponents.
- Looking for information on Unit Testing? You’re most likely to find a piece encouraging you to test first.
- Many developers skip Unit Testing altogether because TDD seemed too hard or too much of a change.
Jacob starts off by assuming one and two proven and so moves on a lengthy demonstration that the most important mentions of Unit Testing in Google have some discussion of Test Driven Development. I will grant Jacob points three and four. Although in part I would expect this to be true since Unit Testing and Test Driven Development come from the Smalltalk community which invented both concepts. We have Kent Beck to thank for writing the earliest frameworks and also the seminal book on Test Driven Development. So they get mentioned together because they were invented together.
The most important fallacy of Jacob’s writing is to assume that TDD is merely about forcing test case to written. TDD is about:
- Simplifying design
- Writing cleaner API’s
- Decoupling
- Reducing the number of bugs written right at the start.
- Thinking about how the caller will see and use your code.
In addition Jacob says that TDD is harder than “Plain Old Unit Testing”. Perhaps, at first as the developer learns TDD, it will be harder but not over the length of a reasonable sized project.
I’ve been on projects where we tried to write all of our tests after the classes were written. Our test suite was valuable and prevented many regressions. But it allowed many issues to slip through. Weaker elements in API’s were often missed and were changed only at a later date at some expense. Tightly coupled code was allowed to evolve making some elements of the application very difficult to test without having to create dozens of other (often unnecessary) objects. As a result of all this it became more difficult to write test cases over time. Would TDD have solved all of these problems? Perhaps not but it would have forced us to confront many of them sooner.
Unlike Jacob I’ve encountered very few people who avoid TDD because they think it’s too hard. Instead the objections I’ve heard are:
- “I don’t understand the benefits”
- “I don’t believe all the claims I’ve heard”
- “TDD won’t work for my project because we build XXX” (Where XXX is your favorite specialized application type: GUI, Web Apps, …)
My suggestion to anyone who tells me it won’t work: Find a mentor; Commit to trying for at least two months. At the end of that time if it still doesn’t work for you then so be it.
Have you been scared off from TDD by the amount of work you believe will be involved with trying to adopt it? Have you been scared off Unit Testing by TDD zealots (such as myself :-)) Have you encountered other reasons that people use for avoiding TDD?
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Nice post!
You may want to take a look at
https://www.infoq.com/news/2008/02/unit_tests_forests_n_trees
for further ruminations on that topic.
Greetings
Mario
I think that the problem could not the opposition between TDD and unit testing, but the lack of unit testing activity in the first place. You could find some hard data on test driven development and unit testing on
* TDD Survey Results by Stelligent (2007)
https://www.stelligent.com/pdf/TDDSurvey.pdf
* Unit Testing: Can You Repeat Please?
https://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest
I personally think TAD (test-after development) is largely a waste of time.
https://langrsoft.com/blog/2008/07/realities-of-test-after-development-aka.html
I have encountered many objections to TDD in the blogosphere. Few admit that TDD is “too hard” (after all, there is one’s ego to protect), but many admit that TDD introduces a significant overhead that they are unwilling/hesitant to adopt. It is hard to know whether all of those that are wary of implementing TDD would also be weary of implementing some degree of Unit Testing, be it test-first, test-last, etc., because most pro-TDD articles do not focus on the value of Unit Testing only.
Personally, I do see value in Test-First design
(https://blog.troyd.net/Test%2bSupported%2bDevelopment%2bTSD%2bIs%2bNot%2bTest%2bDriven%2bDevelopment%2bTDD.aspx), but I think many potential unit testers may be throwing out the baby with the bathwater.
Here’s the URL again (the RegEx parser was a little too hungry):
https://blog.troyd.net/Test%2bSupported%2bDevelopment%2bTSD%2bIs%2bNot%2bTest%2bDriven%2bDevelopment%2bTDD.aspx
Hi,
I think TDD vs POUT is a case of chicken or egg, what’s the big difference when you write the test? Yes I heard that it’s about design and not testing(or both) but really what difference does it make if you design the old fashioned way(prototyping, etc.) or the new flashy way TDD? Cleaner code, fewer bugs, etc.? Well any code is only as good as the developer writing it, and tests can go bad too and paint you’re design in a corner if you make too many false assumptions. TDD is beautiful in theory same as Communism is but it all breaks down in practice. There are simply too many loopholes where TDD is not feasible or not cost effective and the definiton of it is all or nothing so it ends up with nothing or a bloated unmaintainable horde of test cases that prove nothing of relevance.
Micheal – first of all thanks for taking the time to comment. You’re right a weak developer who isn’t interested in improving their code quality will still produce crappy code. In fact a better way of saying it – you can TDD crap. Here’s the thing if I’m coaching your team then one of our goals will be to help improve the code quality.
From my own experience I can only say that I do see the difference when I write the tests first – it forces me to stay focused and simplify the code. I don’t worry about the cases I’m not testing for yet and often they turn to be irrelevant. Perhaps you don’t have the same experience.
You say that TDD has too many loopholes where its not feasible and cost effective – I’m not sure what you mean. What are these cases? If your already doing POUT, why won’t TDD work?
I’m sorry that you’ve found TDD working for you – I suggest only you consider trying it again, perhaps using Coding Katas or Coding Dojos. Perhaps it won’t work for you – but remember at the core of Agile we keep an open mind.
Micheal, excellent observation: “TDD is beautiful in theory same as Communism is but it all breaks down in practice.”
Joe – I approved your comment but don’t you think it courteous to use a real name and email?
As to communism its clear it wouldn’t even work well in theory, if you think about its the waterfall of politics/economics: Central Planning, 5 yr plans etc.
What about the case where the software is highly technical, for instance, Geology and Geophysics exploration software, that requires a certain amount of specialization, usually a MS degree in one or the other of the two disciplines to understand the science behind the software in order to write a useful test. Most User stories do not have the depth to tell the developer how it will be used correctly. For instance: Joe the geologist wants to pick a fault on a vertical seismic amplitude display section along crossline 200, starting at 2.4 msec in formation A continuing to the bottom of formation D utilizing one seed point in each of the four formations. That sounds pretty simple, but there might be a lot of information that the geologist persona knows that the developer does not. I find that the Product Manager who writes the User Stories usually leaves out a lot of information expecting the Geologist or Geophysicist tester in QA to “know” whereas the Developer does not. I can see some of the benefits of the method evaporating in the convoluted path needed to actually put in into play for very specialized software projects.