Let’s see how we can make better looking answers using the “check answer” pattern. Mockito’s Answers are great when you need to verify that a method was called with specific parameters, or you need to execute an operation that also needs to be mocked. I’m sure you have seen situations where Answers were very useful. Let’s dive into a simple example. Our fancy program consists of three classes which are listed in the snippet below.

public class MyRuntimeState {
 
  private boolean state;
 
  public void setState( boolean state ) {
    this.state = state;
  }
 
  public boolean isTrue() {
    return state;
  }
 
}
 
 
public class MyDelegate {
 
  public void doSomething( MyRuntimeState state ) {
    // do some fancy operation
  }
 
}
 
 
public class MyObject {
 
  private final MyDelegate delegate;
 
  public MyObject( MyDelegate delegate ) {
    this.delegate = delegate;
  }
 
  public void operate() {
    MyRuntimeState state = new MyRuntimeState();
    state.setState( true ); // this is the important fact we want to test
    delegate.doSomething( state );
  }
 
}

As you can see we have the Types MyObject, MyDelegate and MyRuntimeState. MyObject needs a MyDelegate in its constructor. In the operate method, MyObject calls MyDelegate‘s doSomething method with a newly created MyRuntimeState object. Let’s assume that for some reason our fake system needs a MyRuntimeState with the state ‘true‘ to work (be creative – it’s just an example ).  So, MyObject needs to set the state of the MyRuntimeState object to true. This is exactly the case where Answers are useful to verify that the state is true within the doSomething invocation (we can probably also do this with verify in this example, but there are harder operations out there where verify can’t be used).  Let’s look at the test for this mechanism.

@RunWith( MockitoJUnitRunner.class )
public class MyObjectTest {
 
  @Mock
  private MyDelegate delegate;
  private MyObject myObject;
 
  @Before
  public void setup() {
    myObject = new MyObject( delegate );
  }
 
  @Test
  public void testSendsRightState() {
    doAnswer( new Answer<Object>() {
 
      @Override
      public Object answer( InvocationOnMock invocation ) throws Throwable {
        MyRuntimeState state = ( MyRuntimeState )invocation.getArguments()[ 0 ];
        assertTrue( state.isTrue() );
 
        return null;
      }
    } ).when( delegate ).doSomething( any( MyRuntimeState.class ) );
 
 
    myObject.operate();
  }
 
}

You see that it’s a fully working test that tests exactly what we want, but it’s also a smell. I dislike several things in the testSendsRightState method. The first thing is the method chaining over several lines. The second thing is that we have an indentation level of three which leads to unreadable code. The third thing is that we can’t see at a glance what will be tested. The fourth thing I don’t like is that the assert statement comes before the actual operate call at least in the writing of the code. The last thing is that this method is way too long.

Let’s try to get rid of most of the smells by simply doing one refactoring. You may say that this is obvious, and yes it is;). We need to extract the creation of the Answer object into a separate method. I name these methods createCheck***Answer (*** stands for a named check) because the answers that will be created are invoking the actual asserts. The result can look like this:

@Test
public void testSendsRightState() {
  Answer<Object> checkStateAnswer = createCheckStateAnswer();
  doAnswer( checkStateAnswer ).when( delegate ).doSomething( any( MyRuntimeState.class ) );
 
  myObject.operate();
}
 
private Answer<Object> createCheckStateAnswer() {
  return new Answer<Object>() {
 
    @Override
    public Object answer( InvocationOnMock invocation ) throws Throwable {
      MyRuntimeState state = ( MyRuntimeState )invocation.getArguments()[ 0 ];
      assertTrue( state.isTrue() );
 
      return null;
    }
  };
}

This simple refactoring has a huge impact on our test method. The test method has only a length of three lines of code now. The indentation level is one. The call chain fits into one line. Even the createCheckStateAnswer is more readable because it’s not surrounded by chained calls. One drawback still resists this solution. That is, that the assert is now called within another method. To me, this is a very low price to pay compared to the problems in the first test. And, the best thing about this solution is that when you only read the test method you see at first glance that an answer called checkStateAnswer was created that obviously does something like check a state. Other programmers should be able to understand most of the test method without reading the createCheckStateAnswer method.

I know that this solution is very simple and for you, may be obvious. But when I started with Answers I didn’t do this for reasons only the Programming Gods know now. If you have any other things related to Answers in your repertoire please share them with us in a comment.

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4

The first one is to write plain JUnit tests and do all the requests yourself within the test methods (maybe with the help of utilities). The other option is to use a library called rest-assured. This library provides a kind of DSL for testing REST APIs. You can write your tests with JUnit and use mockito-like syntax to send a request and test the response. But this doesn’t feel like the right solution, because you always have to configure your request with real Java code within your test method. I would prefer a solution where I can simply configure the request using something like annotations and just execute the test after the request is sent.

Another thing that bugs me are asynchronous services. When it comes to handling asynchronous services you always have two options: callbacks or polling. How can I test those services? For polling it’s easier – you can loop the request code – but does this sound right to you? For callbacks you have to open a server, again within your test method or before. It seems there are no cool solutions for this right now – even rest-assured can’t handle these services very well. That’s why I took a little time and tried to solve these problems. The result is a small library called restfuse.

Restfuse is a JUnit extension. It introduces an annotation called @HttpTest which can be used to configure a request. The request is sent before the annotated method is executed as a test method. The response is then injected into the test object and can be used within the test method. It also provides some new asserts like assertNotFound or assertOk to test response codes. A simple @HttpTest looks like this:

@RunWith( HttpJUnitRunner.class )
public class RestfuseTest {
 
  @Rule
  public Destination destination = new Destination( "http://restfuse.com" ); 
 
  @Context
  private Response response; // will be injected after every request
 
  @HttpTest( method = Method.GET, path = "/" )
  public void checkRestfuseOnlineStatus() {
    assertOk( response );
  }  
}

And of course, it also solves the problem with asynchronous services by introducing two annotations called @Callback and @Poll which can be used together with the @HttpTest annotation. For more information on these tests for asynchronous services take a look at the restfuse site.

Restfuse is open source, licensed under the EPL v – 1.0 and is hosted at github. The 1.0 version is also in the Maven Central and online as a p2 repository (yes, it’s an OSGi bundle).  I hope this small library will help you as much as it helped me. I would appreciate feedback on how to make restfuse even better.

That is, when we want to debug our Object-Under-Test’s real method and the object is a spy. When we try to step into the object’s method we always land in internal Mockito code. After a little reading we can drill deeper but the next landing place is in java.lang.reflect code and so on. To be honest, this is really not the nicest way to debug code. What I want is that regardless of whether I use spies or not, when I step into an object’s method I land directly in this method. In the past my workaround was to set a breakpoint in the test at the method call and in the method itself. This enabled me to stop at the first point and resume the execution until it stops the second time in the method. But there is a much more elegant way. Let’s see how we can do this.

First of all, let’s take a look at an example. The code below shows a simple test from the last Effective Mockito post. The test uses a spy to “pseudo mock” a static method. We set a breakpoint in the line of the isPropertySet call and debug this method. Sadly when doing this we run into the effect described above.

@RunWith( MockitoJUnitRunner.class )
public class MyObjectText {
 
  @Spy
  private MyObject objectUnderTest;
 
  @Test
  public void testIsPropertySet() {
    doReturn( "some runtime property" ).when( objectUnderTest ).getProperty();
 
    boolean isPropertySet = objectUnderTest.isPropertySet();
 
    assertFalse( isPropertySet );
  }
 
}

When using Eclipse there is a very simple way to avoid this called “Step Filtering”. We can add packages or classes to this Filterlist using the preferences. When filters are activated the classes will automatically be skipped during debugging. By setting a filter like the one in the screenshot below we can simply step over the Mockito and reflection code.

If you are not using Eclipse there is probably a similar way to achieve this with your IDE. It would be cool if you would share this tip with us in a comment. Meantime, I hope that Step Filtering is as helpful to you as it is for me.  Finally, I want to thank Fluffi and Frank for getting me to dive into this.

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Testing is one of the most important things in software development. I assume you agree with me because you decided to read this blog post .  It goes without saying that when we develop software we often rely on third party functionality. This does not affect our testing because we can mock objects from third party libraries thanks to Mockito. But there is one thing that always ruins my karma…

That is, static methods. And even worse, static methods that depend on runtime state. I know there are solutions like PowerMock to enable mocking statics, but I think there is a more elegant solution to avoid the troubles with statics -  without manipulating the bytecode and without adding another mocking library, as we would with PowerMock.

Let’s dive into an example to see how. First, take a look at our third party code. In this example I know that I will have to use a static method from the framework which exists in the class FancyFrameworkUtil. The only purpose of this code is to show you that I have to use it and that the third party library changes its return type magically at runtime as the comment says (this sort of thing happens way too often).

public class FancyFrameworkUtil {
 
  public static String getProperty() {
    return "some runtime property"; // this property changes at runtime ;)
  }
 
}

Let’s get to the code we want to write: a highly sophisticated type called MyObject . This type has only one method called isPropertySet which will become API (by this I mean the method will be added to a public interface). The method only checks to see if the value of the third party’s framework has a specific value and returns a boolean depending on the value.

public class MyObject {
 
  public boolean isPropertySet() {
    String property = FancyFrameworkUtil.getProperty();
    boolean result = true;
    if( property.equals( "some runtime property" ) ) {
      result = false;
    }
    return result;
  }
 
}

We now know that the framework method returns a value that can change at runtime but this does not mean we can’t write a test.

public class MyObjectTest {
 
  private MyObject objectUnderTest;
 
  @Before
  public void setUp() {
    objectUnderTest = new MyObject();
  }
 
  @Test
  public void testIsPropertySet() {
    assertFalse( objectUnderTest.isPropertySet() );
  }
 
}

As you can see it’s a very straightforward test. But it’s not complete because we haven’t tested what happens when the framework’s property value changes. We can’t be sure if our MyObject#isPropertySet ever returns true. I’m sure you’ve had a similar problem in the past, too.

At this point we have a choice. Introduce another framework to mock the static framework method or do something like the following. First, we need to extract the call to the third party library in a separate method in our MyObject implementation. It’s important that we change the visibility of this method to package private. This is the price we have to pay. But I don’t think its a high price because this method will not become API and is only visible in the implementation’s package. By separating the interface and the implementation into different packages this really isn’t a problem.

public class MyObject {
 
  public boolean isPropertySet() {
    String property = getProperty();
    boolean result = true;
    if( property.equals( "some runtime property" ) ) {
      result = false;
    }
    return result;
  }
 
  String getProperty() {
    return FancyFrameworkUtil.getProperty();
  }
 
}

This is all we have to do to our implementation to enable the “pseudo mocking” of the FancyFrameworkUtil‘s method. Now comes the testing, and at this point we can use a spy. A spy is a real object with one or many mocked methods. Therefore we can spy on our objectUnderTest. In our case we want to mock the getProperty method that was added last. It can look like this.

public class MyObjectTest {
 
  private MyObject objectUnderTest;
 
  @Before
  public void setUp() {
    objectUnderTest = spy( new MyObject() );
  }
 
  @Test
  public void testIsPropertySet() {
    doReturn( "some runtime property" ).when( objectUnderTest ).getProperty();
 
    assertFalse( objectUnderTest.isPropertySet() );
  }
 
  @Test
  public void testIsPropertySetWhenPropertyChanged() {
    doReturn( "foo" ).when( objectUnderTest ).getProperty();
 
    assertTrue( objectUnderTest.isPropertySet() );
  }
 
}

As you can see in the test methods, the spying in the setUp method enables us to change the return value of the framework’s method by introducing a delegation step. With this we can ensure that our method isPropertySet reacts to changes in the framework’s property.

I hope it’s now clear how to use a spy to mock static framework methods by using delegation steps. If you know alternative ways, please take a minute to share it with us in a comment. By the way, there is also an @Spy Annotation you can use. Have fun spying

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

If you are into unit testing, you may find EasyMock quite useful. It is very valuable for making hard-to-test-code testable.

For example I recently was adding tab-switching via keyboard to Riena. The state of each tab is kept in an interface named INavigationNode which has about 40 methods (!). Creating a mock by hand for such a big interface would not be fun at all. With EasyMock it just takes is a call to:

ISubApplicationNode nodeA = EasyMock.createMock(ISubApplicationNode.class);

The code for determining the next tab, depends strictly on the isSelected property. Manipulating the return value of this method takes just another EasyMock call:

EasyMock.expect(nodeA.isSelected()).andReturn(true);

This tells EasyMock that nodeA.isSelected() will be called once and should return true.

After everything is set-up I switch from ‘record’ to ‘play-back’ mode:

EasyMock.replay(nodeA);

Here’s a full example of a test case:

  protected void setUp() throws Exception {
    super.setUp();
    handler = new SwitchSubApplication();
    nodeA = EasyMock.createMock(ISubApplicationNode.class);
    nodeB = EasyMock.createMock(ISubApplicationNode.class);
    nodeC = EasyMock.createMock(ISubApplicationNode.class);
  }
 
  public void testFindNextSubApplicationAtoB() {
    EasyMock.expect(nodeA.isSelected()).andReturn(true);
    EasyMock.replay(nodeA);
 
    ISubApplicationNode[] nodes = { nodeA, nodeB, nodeC };
    assertSame(nodeB, handler.findNextNode(nodes));
  }

This post barely scratches the surface. Curious? Read this nice EasyMock introduction.

Image: (c) *Micky/flickr. Licensed under creative commons.

My biggest gripes with unit testing has been that I couldn’t get any satisfactory answers to these two questions:

1. Why should I practice Test-First?
2. How do you test the tests?

Concerning the first issue, well we discussed some papers that where trying to answer that question when I attended a software quality course at university. The gist of the results were: There is no statistically significant difference in code quality between Test-First and and Test-Later. (Sorry can’t find links to the papers atm. Holler if you want me to find them and I’ll do some more digging.)

The second issue is discussed often as well: If tests are code and code should be tested, doesn’t that lead to more and more tests? This is sometimes referred to as the stack overflow of unit testing.

The revelation I had was this: These two questions answer each other! What’s the easiest way to test a test? A broken implementation. Where do you get a broken implementation? Just use an incomplete implementation. If you practice  Test-First all your implementations start off incomplete by definition. This means that each assertion in your test is guaranteed to fail at least once, giving you the confidence that the assertions actually perform significant work.

I am often surprised that assertions that I expect to fail actually go through just fine. This usually means one of two things: Either the functionality is already there by some fluke (cf. accidental correctness), or my test is incorrect. In either case I can then fine-tune and adapt the assertions to make sure that they fail and thus test some missing functionality.

Two conundrums solved.