by on February 24, 2008 in TDD

Test Driven Development vs "Plain Old Unit Testing"

Scruffy Looking Cat Herder (aka Jacob Proffitt) recently wrote Test Driven Development considered harmful. Jacob is writing about why he putting-out-the-fire 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:

  1. Unit testing provides benefits when used regularly.
  2. Ensuring that developers write unit tests is the prime benefit of test driven development.
  3. Most unit test advocates are also TDD proponents.
  4. Looking for information on Unit Testing? You’re most likely to find a piece encouraging you to test first.
  5. 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?

Be Sociable, Share!

Related posts:

  1. Test Driven Development best resources
  2. Misconceptions with Test Driven Development
  3. Unit Testing in JavaScript
  4. Test Driven Development for Large Scale GUIs Agile 2007
  5. Acceptance Testing and Eclipse Rich Client Applications – How to do it?

Certified ScrumMaster TrainingIf you enjoyed this post take a look at Certified ScrumMaster Training. We currently have courses scheduled in Ottawa, Montreal, Toronto and Edmonton.


  • http://blog.troyd.net Troy DeMonbreun

    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
    (http://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.

  • http://blog.troyd.net Troy DeMonbreun
  • http://gleichmann.wordpress.com Mario Gleichmann

    Nice post!

    You may want to take a look at

    http://www.infoq.com/news/2008/02/unit_tests_forests_n_trees

    for further ruminations on that topic.

    Greetings

    Mario

  • http://www.martinig.ch/ Franco

    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)
    http://www.stelligent.com/pdf/TDDSurvey.pdf
    * Unit Testing: Can You Repeat Please?
    http://www.methodsandtools.com/dynpoll/oldpoll.php?UnitTest

  • http://langrsoft.com Jeff Langr

    I personally think TAD (test-after development) is largely a waste of time.

    http://langrsoft.com/blog/2008/07/realities-of-test-after-development-aka.html

  • Micheal

    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.

  • Mark Levison

    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.

  • Joe

    Micheal, excellent observation: “TDD is beautiful in theory same as Communism is but it all breaks down in practice.”

  • Mark Levison

    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.

  • Pingback: 每周链接 #56 | Daniel Teng's Blog