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

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

Expand Messages
  • Jeff Grigg
    ... Easy: These (Java) mock object frameworks do *NOT* work with the real object at all: They generate, at run time, alternate implementations for the real
    Message 1 of 115 , Jun 1, 2007
    • 0 Attachment
      --- "Desilets, Alain" <alain.desilets@...> wrote:
      > I don't get it then. If the EasyMock always returns fake object
      > (which have not been recorded from the real object) what is the
      > is the purpose of wrapping the real thing inside of an EasyMock
      > exactly?

      Easy: These (Java) mock object frameworks do *NOT* work with the real
      object at all: They generate, at run time, alternate implementations
      for the real object.

      The Java frameworks create mock implementations of interfaces you
      define. So aside from implementing the same interface methods, the
      mock object instances have *NO* relationship to the real production
      implementation classes, method code, or object instances.

      It may not be immediately clear from Martin Fowler's "Mocks Aren't
      Stubs" example code, but "Warehouse" is an interface: It defines the
      method signatures that can be called, but does not provide any method
      implementations. "WarehouseImpl" is the production implementation
      class. In the "Using EasyMock" example, for instance, the code
      "(Warehouse) MockControl.createControl(Warehouse.class).getMock()"
      would generate a new test-only non-production mock implementation of
      the Warehouse interface. The first couple of calls on it express what
      calls you expect the production Order object to call on the Warehouse
      interface. Then you change the mock object's mode, and let the Order
      object make those calls. Then you tell the mock object framework to
      verify that all the expected calls (and no unexpected calls) were done.

      The frameworks enable you to avoid writing your own "MockWarehouse"
      class (that would implement the Warehouse interface). Instead of
      writing the code for the mock warehouse object, you essentially
      generate it at run time, with method calls.

      http://www.martinfowler.com/articles/mocksArentStubs.html
    • 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.