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

Mocks: How to make sure they behave like the real thing

Expand Messages
  • Desilets, Alain
    Here s a situation I run into all the time. I have a class ClassA which uses ClassB. ClassB is really slow, so for unit testing, TestClassA use an instance of
    Message 1 of 115 , May 31, 2007
      Here's a situation I run into all the time.

      I have a class ClassA which uses ClassB. ClassB is really slow, so for unit testing, TestClassA use an instance of ClassA that is connected to a MockClassB. But TestClassB tests an actual instance of ClassB, to make sure that ClassB itself is working OK.

      For a while, everything goes well.

      Then, I modify method ClassB.methodX(), to add a compulsory argument to it: ClassB.methodX(newArgument). I change TestClassB accordingly (i.e. I make it so that the tests pass newArgument to ClassB.methodX), but I forget to do so for ClassA and TestClassA. In other words, ClassA still invokes ClassB.methodX as though it had no compulsory argument.

      Sine I am working with an untyped language, all my tests still pass. TestClassB is green, because I made the change there. TestClassA is also green because MockClassA is still using the old version of MockClassB, which is now out-of-synch with ClassB.

      Then I test manually using the actual system deployed in a test environment and all hell breaks loose because of course, in the deployed system, I am using a ClassA instance that is connected to an actual ClassB instance, not a mock one.

      How do you avoid this kind of situation and make sure that your Mock objects always behave like the real thing?

      One approach I am experimenting with these days is to make MockClassB be a subclass of MockClassB so that it inherits all of the methods of ClassB. Then I create a TestMockClassB which is a subclass of TestClassB. That way, I know that MockClassB behaves like ClassB, since it passes all the same tests.

      This works somewhat, but I find that making MockClassB pass all the same tests as ClassB involves a lot of work. Often my tests for ClassB were written before I needed a Mock version, and the data returned by the various methods is a bit long, and it's hard to hard code that data into the Mock version.

      Suggestions, comments anyone?

      Thx.


      ----
      Alain Désilets, MASc
      Agent de recherches/Research Officer
      Institut de technologie de l'information du CNRC /
      NRC Institute for Information Technology

      alain.desilets@...
      Tél/Tel (613) 990-2813
      Facsimile/télécopieur: (613) 952-7151

      Conseil national de recherches Canada, M50, 1200 chemin Montréal,
      Ottawa (Ontario) K1A 0R6
      National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
      K1A 0R6

      Gouvernement du Canada | Government of Canada



      ----
      Alain Désilets, National Research Council of Canada
      Chair, WikiSym 2007

      2007 International Symposium on Wikis
      Wikis at Work in the World:
      Open, Organic, Participatory Media for the 21st Century

      http://www.wikisym.org/ws2007/
    • J. B. Rainsberger
      ... I worked on one project trying to organize C code in an OO fashion using various pointer-related idioms I didn t entirely understand. This experience
      Message 115 of 115 , Jun 14, 2007
        George Dinwiddie wrote:

        > J. B. Rainsberger wrote:
        > > I would never use mocks on a C project; but of course, I would never
        > > work on a C project.
        >
        > I've certainly used fakes and stubs on C projects. In fact, the
        > practice lead me to heavy reliance on function pointers long before I
        > started using OO.

        I worked on one project trying to organize C code in an OO fashion using
        various pointer-related idioms I didn't entirely understand. This
        experience rather entrenched my distrust of C.
        --
        J. B. (Joe) Rainsberger :: http://www.jbrains.ca
        Your guide to software craftsmanship
        JUnit Recipes: Practical Methods for Programmer Testing
        2005 Gordon Pask Award for contribution Agile Software Practice
      Your message has been successfully submitted and would be delivered to recipients shortly.