Ant is a freelance Java architect and developer. He has been writing a blog and white papers since 2004 and writes about anything he finds interesting, related to Java or software. Most recently he has been working on enterprise systems involving Eclipse RCP, Google GWT, Hibernate, Spring and J2ME. He believes very strongly in being involved in all parts of the software life cycle. Ant is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

Dynamic Mock Testing

11.04.2010
| 5406 views |
  • submit to reddit

Have you ever had to create a mock object in which most methods do nothing and are not called, but in others something useful needs to be done?

EasyMock has some newish functionality to let you stub individual methods. But before I had heard about that, I had built a little framework (one base class) for creating mock objects which stubs those methods you want to stub, as well as logging every call made to the classes being mocked.

It works like this: you choose a class which you need to mock, for example a service class called FooService, and you create a new class called FooServiceMock. You make it extend from AbstractMock<T>, where T is the class you are mocking.

As an example:

public class FooServiceMock extends AbstractMock<FooService> {

    public FooServiceMock() {
        super(FooService.class);
    }


It needs to have a constructor to call the super constructor passing the class being mocked too. Perhaps that could be optimised, I don't have too much time right now.

Next, you implement only those methods you expect to be called. For example:

public class FooServiceMock extends AbstractMock<FooService> {

    public FooServiceMock() {
        super(FooService.class);
    }

    /** 
     * this is a method which exists in FooService, 
     * but I want it to do something else.
     */
    public String sayHello(String name){
	    return "Hello " + name + 
              ", Foo here!  This is a stub method!";
    }	


To use the mock, you'll notice that it doesn't extend the class which it mocks, which might be problematic... Well, there are good reasons. To do the mocking, the abstract base class is actually going to create a dynamic proxy which wraps itself behind the interface of the class being mocked. To the caller, it looks like the FooService, but it's not actually anything related to it. Anytime a call to the FooService is made, the first thing which the proxy does is log that call, using XStream to create an XML representation of the parameters being passed into the method. Then, the proxy goes and looks in the instance of the mock class to see if it can find the method being called (well at least a method which takes the same parameters and has the same name and return type). If it finds such a method, it calls it. In our example, the sayHello(String) method would get called. It returns the result if there is one, to the caller.

In the case where it cannot find the method, it throws an exception, because it assumes that if it was not implemented, you didn't expect it to be called. You could of course change this to suit your needs, maybe even calling the actual FooService.

So, how to you use the FooServiceMock to create a FooService instance which you can use to mock your service? In the test, where you setup the class under test, you do this:

    FooServiceMock fooService = new FooServiceMock();
	
    //perhaps tell it about objects you would
    //like it to return...
	
    instanceOfClassUnderTest.setFooService(
                               fooService.getMock());	


The setFooService(FooService) method on the instance of the class you are testing is in my case present, but you might not have it and may need to use reflection to do it. It's a question of how testable you write your classes, and is a design choice.

The getMock() method on the AbstractMock class is the method which creates the dynamic proxy which wraps the instance of the mock.

You can now test the class. There is however still something useful you can do after testing, i.e. assert that the right calls were made in the correct order with the right parameters. You do this in the test class to:

    assertEquals(1, fooService.getCalls().size());
    assertEquals("[sayHello: <String>Ant</String>]", 
	                  fooService.getCalls().toString());


The above tests that the sayHello(String) method was called just once, and passed the name "Ant".

There are times when you might want to clear the call log, between parts of the test. For that, call the clearCalls() method on the mock object:

        fooService.clearCalls();


Have fun!

 

From http://blog.maxant.co.uk/pebble/2010/11/03/1288813500000.html

Published at DZone with permission of Ant Kutschera, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: