Women in Technology

Hear us Roar



Article:
  Unit Testing with OCUnit
Subject:   Test Driven Development
Date:   2004-04-24 14:00:18
From:   dsteinberg

You need to consider the purpose of your tests. If they are intended just to test your code then your process is fine. But the reason it is called Test Driven Development is that the tests are what help specify the code you are writing. The tests really are driving the development and some people will not write any production code without a failing test.


Forget about TDD in its current incarnation and go back almost twenty years to the early days of Objective-C. Brad Cox explained in his classic book on OO that the way he discovers and shapes his objects is by considering client code. What are the needs of the code that will call into these objects? TDD starts there. You first write the client code and that points you in the direction of the object being crafted.


I don't understand why, if you are going to write a full set of tests anyway, you wait until you write a "large chunk of the application". A growing suite of unit tests lets you know that your application is compiling and has the correct behavior at all times.

Full Threads Oldest First

Showing messages 1 through 2 of 2.

  • Test Driven Development doesn't *always* work
    2004-04-24 15:59:02  gaeldesign [View]

    I don't understand why, if you are going to write a full set of tests anyway, you wait until you write a "large chunk of the application".

    Because if you are experimenting with software architecture and may be drastically refactoring code or even scrapping it and starting over from scratch, then writing the tests first is far too tedious and drains creativity. I've tried several times to use TDD when starting out with basic software architecture, and it doesn't work for me. It's far easier to get the code to a somewhat useful and stable state, and then write the tests you need to make sure the code is working correctly.

    I think TDD is probably great for large apps with large development teams that are working on various chunks of the codebase separately and need to do sanity checks often, but for small-scale developers...especially "one-man" developers like me...TDD is sometimes overkill.

    Just my 2c,

    Jared
    • Daniel H. Steinberg photo TDD and Refactoring
      2004-04-26 11:00:05  Daniel H. Steinberg | O'Reilly AuthorO'Reilly Blogger [View]

      I can agree that TDD isn't right for everything and may not be right in your situation. I also am not trying to be argumentative, but TDD seems to be right in the sweetspot of what you are targetting. It can help you discover an appropriate software architecture and it covers your backside if you find you have gone down the wrong path. While you do dramatic refactorings, a suite of tests keeps your app working.



      Of course, I'm a bigot about this. For me, of all of the practices described in XP and related methodologies, TDD was life changing. It was what made my code more robust and flexible.



      D