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

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

Expand Messages
  • Joseph Gutierrez
    [snipstart] ... to it: ClassB.methodX(newArgument). I change TestClassB accordingly (i.e. I make it so that the tests pass newArgument to ClassB.methodX), but
    Message 1 of 115 , May 31, 2007
    • 0 Attachment
      [snipstart]

      --- In extremeprogramming@yahoogroups.com, "Desilets, Alain"
      <alain.desilets@...> wrote:
      >
      > 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.
      >

      [snipend]

      From what you are describing, there is some functionality that is
      changing. Have you tried encapsulating what is changing from ClassB.
      Extract that varying functionality from ClassB. Usually when I end up
      with a cascade effect like your describing it means I don't have enough
      separation of concerns.

      I worked on a text file parser. Instead of passing in a file name I
      passed in a TextReader Interface. That way during unit tests I created
      TextReader from a string. No dependency on a text file sitting on the
      drive. As the unit tests kept growing the string would change, like for
      instance needing to add more text cases for parsing. Eventually I went
      ahead and created a class with static getters for the strings and
      modified my tests to call these static getters.

      Hey! This just popped into my mind. Have you tried reversing the
      dependencies. If ClassB is changing then pass ClassA into ClassB. Have
      ClassB load whatever specific data ClassA needs. Use setters in ClassA.
      Now ClassA doesn't need ClassB for unit testing. Also ClassB will need
      ClassA for its unit testing which may force ClassB to become more
      stable. Maybe the solution is a dependency re-arrangement? I think the
      dependency flow should be, less stable class should depend on the more
      stable class.

      Hope this helps!
    • 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
      • 0 Attachment
        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.