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

RE: [XP] refactor test code?

Expand Messages
  • Amir Kolsky
    ... testing-only mock/stub of the abstract class. ... The thing I was trying to address is the division of responsibility. I you define an interface or any
    Message 1 of 9 , Nov 29, 2003
    • 0 Attachment
      <kolsky@a...> wrote:
      >><quote> [not sure who said this - Bill]
      >>If you test a virtual method, your test method should be
      >>virtual. If you test an abstract method, your test method
      >>should be abstract, and
      >>should be implemented by the derived test.
      >I don't do it this way. I generally write a concrete test of a for-
      testing-only mock/stub of the abstract class.

      >For example, the abstract class AC may have an algorithm using
      >template method, where subclasses SC will replace abstract methods
      >with steps appropriate to themselves. I will create TestAC (or
      >ACTest:), with an inner class MC (in Java, anyway) which extends AC
      >and implements the abstract methods in whatever way makes it easy to
      >test. Each subclass will have its own test as well. There may be
      >some overlap in coverage of the algorithm, but if the subclass is
      >simple enough, I may not feel it needs it.

      >The reason I do this is that I want to test the abstract class on
      >its own terms. There may be no "natural" subclass that will do this
      >completely, and I'd rather not wait to find out about any problems.

      The thing I was trying to address is the division of responsibility.
      I you define an interface or any abstract entity you are in fact writing
      a contract. You stipulate how the methods of the interface should be
      called and the implementer needs to make sure the implementation behaves

      This means that the tests that test an interface should be written by
      the interface designer (specified) and that the implementation should
      comply with these tests.

      However, in some cases, especially when it comes to abstract actions,
      what's known about the implementation is the circumstances that it is
      called. Not what it is supposed to do. In this case, it is the onus of
      the implementation author to actually specify the tests. The interface
      author specifies that a test should be written, the implementer writes
      the test. This is analogous to the case that the interface species that
      code should be written and the author writes the code.

      This does not preclude the implementer from writing more tests, *but* if
      the interface specifies how the code will be used, and specifies the
      tests that need to be passed. Wouldn't writing more tests constitute a
      YAGNI? I.e., wouldn't writing tests outside of the prescribed context
      lead to unneeded complexity?

      Someone might argue that the interface specified tests are really
      acceptance tests, as the interface is the "client" of the
      implementation. This is because if you need to pass tests that were
      already written for you, you are not writing them one at a time as per
      TDD... That might be the case when it comes to passing the interface
      *Written* tests. However when the InterfaceTest specifies that you need
      to write a series of tests, it is more of a to-do list than an
      acceptance test.

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