Test Driven Development…

Recently during the 'first official meeting of the Managed DirectX fanclub' (as Dave called it), Craig mentioned something he's been doing recently called 'Test Driven Development'

It *sounds* like a lot more upfront work, but the process intrigues me.  Anything that can help eliminate bugs, and regressions has got to be a good thing.  I'm curious what other people's experience in this field is.  Craig even mentioned than he found he was even more productive, which was at least somewhat surprising given the extra work involved.

Of course, it makes me wonder.. If I have to write the test before i implement the method and i'm designing a library, i can't even make the test compile until i've defined the method.  It's like a catch-22! =)

Comments (7)

  1. Ivana Vackoff [MSFT] says:

    You mean all 5 members of the fanclub?

  2. Craig Andera says:

    There were four of us, actually. Who did we miss? 🙂

    On the TDD front, this [1] might help, particularly the series "The Craftsman".

    You’re totally right about the test not compiling. That’s part of the process: write the test to help, drive figuring out what methods you need, then implement the methods so they do nothing. Then ensure that the test *fails*. Then code just until it works.

    The biggest challenge is figuring out how to deal with code you don’t own, like the controls on a form or DirectInput. But there are ways around that, too.

    [1] http://www.objectmentor.com/resources/listArticles?key=topic&topic=Test%20Driven%20Development

  3. Russ says:

    Test driven development is absolutely the way to go. If you haven’t tried it, go straight to csunit.org and get the plug-in for Visual Studio.

    Once you start automating your unit tests, you will be able to confirm correct operation, and you will build a better design.

    Finally, refactoring is great with this approach. If you change something, re-run your unit tests. If anything breaks, you know what impact your refactor does.

    Highly recommended…


  4. .. says:

    "Buy my product"

  5. Brandon Hamm says:


    “If I have to write the test before i implement the method and i’m designing a library, i can’t even make the test compile until i’ve defined the method. “


    This is the mantra for the “hard-liners” behind TDD. The thought process being not one line of functionality is added to a method/property/etc unless it is deemed required by a failing test. LOL….There’s a hilarious chapter in “Agile Software Development” that chronicles the course of a very small Java app being developed by the books authors. This actually a case that they took the time to document:

    < paraphrase>

    – (author #1): “Oh, the test failed…guess that means we need to define a method.”

    – (author #2): “You got it.”….”Ok, let’s run the test again.”

    – (author #1): “Alrighty…so, what’s next?”


    It is actually a good book, and TDD definitely has some excellent merits IMHO, but as with any development methodology…there are always the fanatics…along with those of us that can smile and chuckle at them.

    – Brandon

  6. Russ says:

    To whoever said "Buy My Product"…

    1) csunit is free.

    2) I don’t have anything to do with csunit.

    3) csunit is an open source project based off of junit (for Java.)

    So, the "buy" is wrong. The "my" is wrong. And, the "product" is wrong…

    Otherwise, your post is dead on.


  7. Jonah says:

    I have been working toward integrating TDD in my everyday development as much as I can, and I *have* to agree that it has improved my code tremendously. I am now more productive (seems counter-intuitive but it’s true), my code is more solid, and my design is several orders of magnitude better.

    There are challenges to using TDD, especially in a position where I am doing a lot of UI work in a team that doesn’t believe in it.

    All I can say is, try it for a month. Only then can you have an informed opinion about TDD. As everyone knows, an uninformed opinion is not a significant opinion 😉

Skip to main content