mockobjects-java-users

[Mockobjects-java-users] Question on best practices

[<lau...@ma...>]

Hi,

I'm in the process of writing some tests with Cactus and MO. Iwant to
simulate some Session Beans so I've written mock objects for them. Some of
our session beans have a create() method to simulate the corresponding home
interface method from the session bean interface. When I implement my mock
object, should the create() method actually create a real object and return
it (so, I would have to create another  mock to implement the interface I'm
trying to create)? Or should I set up the object beforehand and have the
create() method make sure it is called and then return the data I have
previously set up?

Hope it's not too confusinng an explanation.

L

-- 
Laurent Duperval <mailto:lau...@ma...>

Windows 3.1:  The 8MB patch.

Re: [Mockobjects-java-users] Question on best practices

[Steve F. <st...@m3...>]

From: <lau...@ma...>

> trying to create)? Or should I set up the object beforehand and have
the
> create() method make sure it is called and then return the data I have
> previously set up?

What are you trying to test? If you want to test that some other code
talks to the create() method correctly, then I would check that it's
called appropriately and pre-load the result. The point is to mock up
the environment around so that you can isolate the code under test. On
the other hand, if it's easy to create and instance and you don't need
to do anything with it in the rest of the test, then maybe you could
just assert that the object returned from create() is of the right type?

Do you have an example?

S.

Re: [Mockobjects-java-users] Question on best practices

[<lau...@ma...>]

On  8 May, Steve Freeman wrote:
> Do you have an example?
> 

Well, something like this:

Foo methodToTest() {
  ObjectHome home = mockFactory.getHomeObject();
  Object o = home.create()

  return o.getFoo();
}

In order for this method to be tested correctly, o has to be avalid object.
I have two way of doing this: either Home.create() implements all the logic
to create a correct Foo object (and in our case, sometimes that's a
multi-step operation) or I add a setupFoo(Foo o) method that will
effectively do the same thing, but the multi-step operation occurs outside
of the mock object that is returned by getHomeObject().

I think what I need to understand is where do I stop reimplementing the
logic of my real application in the mock object?

L

-- 
Laurent Duperval <mailto:lau...@ma...>

There are two rules for success in life:
Rule 1:  Don't tell people everything you know.

Re: [Mockobjects-java-users] Question on best practices

[Steve F. <st...@m3...>]

From: <lau...@ma...>
> On  8 May, Steve Freeman wrote:
> > Do you have an example?
>
> Well, something like this:
>
> Foo methodToTest() {
>   ObjectHome home = mockFactory.getHomeObject();
>   Object o = home.create()
>
>   return o.getFoo();
> }
>
> In order for this method to be tested correctly, o has to be avalid
object.
> I have two way of doing this: either Home.create() implements all the
logic
> to create a correct Foo object (and in our case, sometimes that's a
> multi-step operation) or I add a setupFoo(Foo o) method that will
> effectively do the same thing, but the multi-step operation occurs
outside
> of the mock object that is returned by getHomeObject().

In that case, then you would probably want a mock factory, mock home
object, and mock o. It's a pain, but it's quite easy to set up using
anonymous implementations in the test class until the mock gets useful
enough to pull out into its own class: e.g.

public void testMethodToTest() {
    final Foo aFoo = new Foo();
    final AnObject mockO = new AnObject() {
       public Foo getFoo() {
          return aFoo;
       }
    };
    final ObjectHome mockHome = new ObjectHome() {
      public AnObject create() {
        return mockO;
      }
    };
    Factory mockFactory = new Factory() {
      public HomeObject getHomeObject() {
         return mockHome;
      }
    };

    testObject.setFactory(mockFactory);
    assertEquals("Should be a foo", aFoo, testObject.methodToTest());
}

or some such madness. It shouldn't be long before you can refactor out
all this setup into something more readable.

> I think what I need to understand is where do I stop reimplementing
the
> logic of my real application in the mock object?

almost immediately. If you reimplement the real application, then you've
just got more to test.

S.