Why do TDD?

Because sometimes your test passes the first time you write it. Either you’re done writing any more code, or your understanding of how your code is supposed to work is wrong. Both paths lead to a better spot than without tests. Writing this because a test I wrote passed, exposing a misunderstanding on how a system I’ve worked on for months.

Getting to a failing test is half about characterizing the behavior you want to see in your system, and half about challenging an assumption on whether your system behaves today how you think it behaves. And challenging assumptions through such a cheap mechanism as an automated test is always a good thing.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I hope you don’t mean only unit tests but also integration ones. Recently I reviewed the way Castle is tested and must admit that being strict to unit tests is not always the best way.

    • Anonymous

      For me, TDD != unit tests. I’m very deliberate when I mention TDD that I don’t mention unit tests. TDD just means test-driven development, not “unit-test driven development”.

  • Fir3pho3nixx

    One thing you could say is that TDD is perhaps as much as design activity as what it formalizes assumptions(all benefits). I find that in order to write better, easier to understand tests that prove behavior or interaction, you naturally tend to evolve your code in properly separated, single responsibility objects. Gone are the days of dealing with entangled messes for which there is no evidence to support that it works! :)

  • I totally agree, failing test are mostly more enlightening than succeeding tests – or at least trigger a deep review of your system’s understanding.

    One thing though: Sounds more like you were talking about some sort of ‘test-after’ scenario,  not necessarily about TDD.


    • Anonymous

      Test-after? Curious, what gave you that impression?

      • What I imagined from your post was a developer staring at some alien code (e.g. some legacy codebase, or possibly adding some additional tests to a TDD-driven codebase), writing a test for it, and then being surprised because the test passed unexpectedly.
        This would be close to my experiences, so that’s what I understood from your post.
        But I’m suspecting from your question that this not the case. Right?

        • Anonymous

          Ha, well, no it was my own code (which is often alien to me). But doing test-first, the first step is to write a failing test. Sometimes that test that is supposed to fail, actually passes.

  • Andrew Reiser

    TDD is rubbish. Expensive beyond what customer’s can afford. I’m currently watching a test driven project crash and burn. It aint pretty.

    • Anonymous

      Ha! Fair enough. It sounds like you may be describing a symptom, however. What is expensive about TDD? (In my experience, only the very smallest projects have any expense of TDD, unless there is a lack of technical leadership on the project)