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

Re: Test execution speed

Expand Messages
  • Dominic Williams
    ... I appreciate the importance of executing full unit tests in a very short time. However, TDD is also a design technique. I have observed that mocking or
    Message 1 of 260 , Aug 2, 2004
      J. B. Rainsberger wrote:

      > My #1 testing goal is to be able to test every single
      > object in complete isolation from the implementation
      > details of its collaborators--that is, nothin' but
      > interfaces. The result of achieving 95%+ of this goal
      > is 100 tests per second, or 60,000 tests in 10
      > minutes.

      I appreciate the importance of executing full unit
      tests in a very short time.

      However, TDD is also a design technique. I have
      observed that mocking or stubbing make it possible to
      unit test fragile, rigid, highly coupled designs. I
      feel therefore that unit testing without mocks or stubs
      has a more positive influence on the design. This is
      important when working with teams in which everyone may
      not be a long-seasoned OO programmer.

      Another concern I have with respect to your approach is
      that although the application's classes have been
      decoupled, the unit tests have become coupled with the
      code's implementation.

      An important aim of object-oriented design is hiding
      the implementation details. I have found TDD to be very
      useful in helping programmers think about objects from
      an external, client perspective. Tests coded this way
      are independent of the implementation of the object
      under test. Stubbing or mocking the collaborators of
      the object under test makes the tests dependent on that
      implementation. On long-running projects, I have
      observed that this has two drawbacks:

      1) the code/test base is less flexible: each change
      requires more work.
      2) refactoring is less safe: it is almost always
      necessary to change both code and unit tests at the
      same time.

      The approach I favour is therefore only to stub
      external, performance-unfriendly things such as
      databases and filesystems. Sure, every now and then, it
      becomes necessary to optimise the unit test run. I view
      this as a good thing: it usually leads to removing
      duplication in the tests, which makes them more
      readable and maintainable, and optimising the code
      itself, which then benefits the application.

      Regards,

      Dominic Williams
      http://www.dominicwilliams.net

      For a software-patent-free Europe:
      http://www.noepatents.org

      ----
    • Ilja Preuss
      ... Yes, but I thought that we were talking about a test that was wrong. Not sure wether that matters, though... Cheers, Ilja
      Message 260 of 260 , Aug 18, 2004
        Adrian Howard wrote:
        > On 17 Aug 2004, at 12:22, Ilja Preuss wrote:
        > [snip]
        >> It's certainly the case that without pairing/reviews I am more
        >> likely to
        >> *miss* tests - but I don't think that I get more *wrong* tests that
        >> cancel out with wrong implementation...
        >
        > I think it could happen over time.
        >
        > - Lack of pairing might mean I miss duplication so a bit
        > of business logic gets into foo and bar.
        >
        > - My acceptance test for the business logic only uses foo.
        >
        > - Later I change bar incorrectly, but the foo test still passes.
        >
        > False-pass for that bit of business logic.

        Yes, but I thought that we were talking about a test that was wrong. Not
        sure wether that matters, though...

        Cheers, Ilja
      Your message has been successfully submitted and would be delivered to recipients shortly.