Loading ...
Sorry, an error occurred while loading the content.

[extremeprogramming] Re: Test First Design

Expand Messages
  • Michael C. Feathers
    ... From: Robert C. Martin ... When ... The ... the ... test ... Yes. for me it usually happens at the application interface. For
    Message 1 of 51 , Jan 5, 2000
    • 0 Attachment
      ----- Original Message -----
      From: Robert C. Martin <rmartin@...>
      > According to Kent, Ward once said that writing tests first is a design
      > strategy, not a testing strategy. This certainly seems to be so.
      When
      > we write tests first we force ourselves into the role of the user.
      The
      > tests are going to use the code we will be writing. So, by writing
      the
      > tests, we are forced to design the production code we are testing.
      >
      > In my experience, this technique has certainly improved the interfaces
      > of the classes I was writing test cases for. But does it go further
      > than that? Has anyone had an experience where a fundemental design
      > concept having far reaching effects, was discovered while writing a
      test
      > case?

      Yes. for me it usually happens at the application interface.
      For instance, I've been working on a test-first tool for the
      Microsoft Visual C++ IDE. I've forgotten which sin I'm
      atoning for, perhaps using it in the past. It is the IDE
      I'm most familiar with that has a good extension API.

      Anyway, something like this could just be knocked
      up using procedural scripts that operate on the IDE's
      object model directly, but that is not directly testable.
      To faciliate testing, I've created an application context
      interface. It is subclassed during test to mimic the IDE.
      I think that the responsibilities have migrated in a way
      which makes it possible for this set of commands to
      operate against other environments. I haven't tried it,
      but I think that it is very useful side-effect of the testing.

      In the past I've had similar things happen. You end
      up making some sort of facade allow tests to drive
      a piece, and then you wonder how you could have
      ever lived without that interface.

      To be quite honest, this is one reason why I'm not
      too keen on driving tests through a GUI. If you don't
      you are forced into making a useful facade.

      Michael

      ---------------------------------------------------
      Michael Feathers mfeathers@...
      Object Mentor Inc. www.objectmentor.com
      Training/Mentoring/Development
      -----------------------------------------------------
      "You think you know when you can learn, are more sure when
      you can write, even more when you can teach, but certain when
      you can program. " - Alan Perlis
    • Martin Fowler
      ... And I think this is a very important value of DbC, but also the one that is hardest to do without Eiffel. Martin
      Message 51 of 51 , Jan 6, 2000
      • 0 Attachment
        > But a key for me is I like to see the contract in the interface
        > documentation. Maybe it is more concise or maybe it is just more
        > "traditional", I don't know. It seems more concise and less vulnerable
        > to ambiguity.
        >

        And I think this is a very important value of DbC, but also the one that is
        hardest to do without Eiffel.

        Martin
      Your message has been successfully submitted and would be delivered to recipients shortly.