35 responses to “Twelve Benefits of Writing Unit Tests First”

  1. Jeffrey Fredrick

    Good list! I forgot #4 when writing my own article on the advantages of TDD over unit testing after the fact, and it is an important one.

  2. Jeff

    Do you mean “trips over his own feeT backpedalling”?

    (OK, so they trip over their own data feed. Very funny. 😉

  3. John Carter

    Some more….

    N) Pins Functionality. If you don’t have a Unit Test for some functionality, don’t whine if your colleague in a later release breaks / masks / removes or otherwise destroys functionality you implemented.

    M) Stops Bug Ping/Pong dead. Bug ping/pong is where the fix to a bug in interrelated functionality creates a bug and the fix to that bug recreates the first bug and the fix to that bug ….

    O) Tests are code too, so tests also have bugs. By writing them test First, so they fail (when they should), you test the tests.

  4. Joshua

    #7 is why I don’t always like to write unit tests before I start coding. My unit tests start coming part of the way into coding when I don’t really know what the final result will be until I’ve explored what needs to actually be done.

    Joshua

  5. Coding Horror

    I Pity The Fool Who Doesn’t Write Unit Tests

    J. Timothy King has a nice piece on the twelve benefits of writing unit tests first. Unfortunately, he seriously undermines his message by ending it with this: However, if you are one of the [coders who won’t give up…

  6. Paul Coddington

    “Write enough code to get the test to pass, but no more.”

    This is a flashing red light for me – people taking this too literally and producing something that fails as soon as it is put into the real world through not being flexible enough (eg: hard-coded paths allow the test to pass). Some authors are not communicating clearly that this means ‘don’t add unnecessary bells and whistles’ (good), rather than ‘limit the code to a literal set of cases and results’ (foolhardy).

    However, that’s not a problem with the methodology, but I have in the past been badly burnt inheriting a failed project from a test-driven enthusiast who thought he was following a failsafe methodology but ended up proving that “there is no substitute for knowing what you are doing.”

  7. Happy Developer

    […] J. Timothy King’s Blog » Blog Archive » Twelve Benefits of Writing Unit Tests First Why do programmers hate writing unit tests? Why do they hate even more writing unit tests before coding? You don’t have to answer. I’ve already heard the excuses. These are rhetorical questions. I have a theory, however, what the real reasons are. Most software developers have never seriously tried test-first. Or if they tried it, they did not do so in a supportive environment where they could learn what they were doing. But more likely the former. So they come up with excuses: “We don’t have time to write unit tests.” Or: “Unit tests can’t bullet-proof your code.” They’re reacting out of fear, not out of empowerment, trying to find reasons for being miserable, rather than making their lives better. The neat thing is that occasionally you’ll find one of these developers who, when you face him with the facts, nearly trips over his own feed backpedalling. That’s fun to watch. And he does this all without ever taking back his opinion of test-first. That’s wicked philosophical. […]

  8. Orbiz Technology Blog

    Twelve benefits for doing TDD

  9. Paul, Kerri and The Boys » links for 2006-07-30

    […] Twelve Benefits of Writing Unit Tests First TDD (tags: pm scrum work sdlc) […]

  10. Exploded Clown » Blog Archive » Twelve Benefits of Writing Unit Tests First

    […] Twelve Benefits of Writing Unit Tests First: How do you solve a software problem? How do they teach you to handle it in school? What’s the first thing you do? You think about how to solve it. You ask, “What code will I write to generate a solution?” But that’s backward. The first thing you should be doing— In fact, this is what they say in school, too, though in my experience it’s paid more lip-service than actual service— The first thing you ask is not “What code will I write?” The first thing you ask is “How will I know that I’ve solved the problem?” […]

  11. Йордан Димитров

    Интересни връзки 2

    C# Best Coding Practices
    Naming Conventions for UI ControlsStringBuilder
    vs. String / Fast String Operations…

  12. Twelve benefits for doing TDD « exceptionz

    […] J. Timothy King list the following twelve benefits you get from doing Test-First programming: […]

  13. links for 2006-10-18 « Ashish Kulkarni’s Journal

    […] Twelve Benefits of Writing Unit Tests First The ones I found significant: […]

  14. J. Timothy King’s Blog » Blog Archive » Does Bad Writing Reflect Poor Programming Skills?

    […] Understand the material before you write. If you understand the material, you should be able to explain it to a four-year-old. If you don’t understand it, you won’t be able to explain it to anyone. You’d think this would go without saying. You’d think that programmers particularly would understand the code they write. But frequently they don’t. If they did, they would use unit tests. Instead, they tweak and hack until the code does what they think it’s supposed to. And they end up with a mess. And then they do it to their comments and other documents, too. This is what causes a lot of comments like “This member is the anticipation for audio data to synchronize with the video frames in an interleaved AVI.” The developer who wrote this probably knew how to tweak the data value to get the result he wanted. But he very possibly did not understand what that value actually represented and how it conceptually fit into the rest of the system. […]

  15. Geek Drivel » Blog Archive » “Twelve Benefits of Writing Unit Tests First”

    […] ran across this post today. It’s more than a year old, but it’s still quite […]

  16. Blog-to Show Visitors, Welcome! » J. Timothy King's Blog

    […] “Twelve Benefits of Writing Unit Tests First” […]

  17. Doug

    I am new to TDD, having been driven there in desperation after my brain ran out of space to contain enough of the code in working memory to debug it. When you need a bigger brain, it’s time for unit tests.

    As a newbie (but I hope a rational one) I am assessing the pros and cons of this approach.
    Pros: No need for a bigger brain
    I can write tests in the language of my choice (python & numpy in my case)
    [insert 12 other reasons here]

    Cons: I am writing mathematical functions so I still need code to generate the tests (unless I test at the level of A=B*C, which is silly), so the code is written twice
    Significant refactoring of code requires significant refactoring of the tests unless I write the “God test” which is useful, but hardly TDD

  18. TDD in ASP.NET MVC Applications with Moq Framework « KakimotOnline

    […] Using the Red-Green-Refactor mantra, we can create testable ASP.NET MVC controllers and benefit from the use of TDD. So, let’s […]

  19. The Android Three-Pronged Attack Test Plan | MokaSocial

    […] to make sure your model classes are doing what you expect them to do, and there are lots of side benefits as well. The Android SDK makes it easy to create a jUnit test project. Unit tests, it’s […]

  20. Vijay

    Tim, Very good Unit Test points which you have mentioned above.

  21. The Art of Software Maintenance - Mrinal Wadhwa on Rich Internet Applications

    […] Monitor The “Works on My Machine” Syndrome I Pity The Fool Who Doesn’t Write Unit Tests Twelve Benefits of Writing Unit Tests First Code Tells You How, Comments Tell You Why Discipline Makes Strong Developers The Law of Leaky […]

  22. David Wallace

    I would agree that 4, 7 and 10 are benefits of TDD. However, the other 9 benefits on this list (and the 3 that were posted later) are just benefits of writing unit tests. In other words, they apply equally to code-first test-afterwards development, provided you are disciplined enough to write the unit tests every time.

    So they’re all good points, but I feel that the title is misleading.

    To me, it seems that one of the most important benefits of TDD is that you avoid the sort of scope creep that results from the developer thinking “we might need this feature later”, when there’s actually no requirement for it. Your application ends up consisting of the minimum possible amount of code that will meet the requirements, with no redundant logic or built-in bloat.

  23. Doug

    I think it needs to be made clear that TTD (Test To Destruction) has severe limitations.

    1. As a designer, I cannot specify (or write) a unit test for “UI must look good and be intuitive to use”. TTD makes coders think they’ve done a great job, with little green lights to prove it, when in real (user) terms they’ve done a horrible job.

    2. I cannot write a unit test for “The result of the CFD simulation must be this set of 1e6 X-Y-Z-V values” – how do I generate the test data? Back of an envelope? Excel?

    3. The tests need access to the production code, and the more detailed the tests, the lower level the access – breaking encapsulation.

    Not trolling, just spouting heresy.

  24. David Wallace

    Responding to Doug – it seems to me that you’ve missed the point of what TDD is about. It’s really not a testing methodology; it’s a design and development methodology. The idea is that by framing your requirements in the form of test cases, you can be sure that your application code meets its requirements, and also that you don’t end up writing code that doesn’t contribute to a requirement. TDD is therefore primarily producing a design for your code; the unit tests are just an added bonus.

    Your point 1 – it’s true that TDD won’t design your UI for you, or produce tests for usability or “nice looking” UIs. But there are other techniques for doing this. TDD won’t make your morning coffee either; but it’s a mistake to consider this a shortcoming.

    Your point 2 – you absolutely CAN write a unit test that requires the output of your process to be a million or so well defined values. So long as you have those values in some usable form, such as a database or a CSV file, you can write a test that runs your process and checks its output. However, such a test would be brittle and unfocussed, and wouldn’t really fit into TDD.

    Your point 3 – your tests need the same access to the SUT as other clients of that SUT. This doesn’t break encapsulation. In Java, for example, you’d simply put your test classes in the same package as the SUT, or as clients of the SUT; then there’s no need to provide special low level access for your test classes.

  25. Twelve Benefits of Writing Unit Tests First « SridharKan

    […] Twelve Benefits of Writing Unit Tests First […]

  26. Testing – a n00b’s reflection | Learn With Jeff

    […] benefit to testing first, as I see it, is as it concerns the thought process towards your code. As J. Timothy King States: You ask, “What code will I write to generate a solution?” But that’s backward. The […]

  27. Day 8 by You Can Learn iT

    […] take to heart. If you care to read more about why testing is important there are other blog posts that will provide a much more in-depth analysis than  I. However I will quote […]

  28. saranya

    hi,
    Is it able to prove TDD is better then code inspection.if possible please send related paper to this id.saranarunmallur@gmail.com

  29. Advantages of Test-Driven Development | Agile Pain Relief

    […] articles that discuss the benefits of TDD: Twelve Benefits of Unit Tests, Research Supports The Effectiveness of TDD, TDD Research Findings, How TDD improves development […]