With this effective Mockito Post I want to share a really simple pattern with you. We call this pattern “check answers” and we use it whenever we work with Mockito Answers. The code resulting from creating Mockito Answers generally looks ugly. But, as good programmers we care about test quality, right?

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

Tags: junit, Mocking, Mockito, Software craftsmanship, testing

In the previous Effective Mockito post we saw how to use the @Mock Annotation to get a clean test. In this post I want to show you how to use Mockito’s spy mechanism to eliminate testing troubles with third party libraries.

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

Tags: junit, Mocking, Mockito, Software craftsmanship, test driven, testing, tips

As promised in the first part of the “Effective Mockito” blog series, I will concentrate on Mockito specifics in the followup posts. So, the main topic for Part 2 is Mockito’s @Mock Annotation.

When I write tests I try to follow an explicit pattern, called the build-operate-check pattern. This was described by Uncle Bob in his book “Clean Code” (Page 127, Chapter 9). The main idea behind this pattern is that you try to split your test method into three parts. The first part sets up the environment, the second executes the method you want to test and the third part verifies the expected. You can also apply this pattern with Mockito using the @Mock Annotation.

When writing tests we often reach a point where we need a second object to get an object under test to work. That’s where we can use mocks . The test code looks roughly like this:

public class SecondPartTest {
 
  @Test
  public void testSomething() {
    Strategy strategy = mock( Strategy.class );
    Something objectUnderTest = new Something( strategy );
 
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
}

As you can see we created an object of the type Something. This object needs another object of the type Strategy in its constructor and I decided to use a mock for this. After this we execute the method we want to test which is called doSomething. The doSomething method should invoke the method doSomethingConcrete on the object we passed in the constructor. As you’ve probably noticed, it’s the strategy pattern. I chose this one because it’s a perfect fit for the use of mocks. In the last step of the test we verify that the method doSomethingConcrete was invoked. Nothing special here.

It looks like a nice and clean little test to me. But, in most cases we have more than one test method in a test class. When a new test method is added, it could look like this:

public class SecondPartTest {
 
  @Test
  public void testSomething() {
    Strategy strategy = mock( Strategy.class );
    Something objectUnderTest = new Something( strategy );
 
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    Strategy strategy = mock( Strategy.class );
    Something objectUnderTest = new Something( strategy );
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

At this point our nice and clean little test is no longer as nice or clean. By adding one test method we introduced two redundant lines of code, the object instantiation and the mocking. This is a sign that we need to use fields for both the objectUnderTest and the mock, and create them in the @Before method as in this snippet:

public class SecondPartTest {
 
  Strategy strategy;
 
  Something objectUnderTest;
 
  @Before
  public void setUp() {
    strategy = mock( Strategy.class );
    objectUnderTest = new Something( strategy );
  }
 
  @Test
  public void testSomething() {
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

This makes our test methods clean again, yippee . But I think we can do better. Mockito provides MockitoAnnotations and I’d like to use one of them in our test. It’s called @Mock (surprise).  Using this annotation we can tell a field that it is a mock.  It can look like this:

public class SecondPartTest {
 
  @Mock
  Strategy strategy;
 
  Something objectUnderTest;
 
  @Before
  public void setUp() {
    MockitoAnnotations.initMocks( this );
    objectUnderTest = new Something( strategy );
  }
 
  @Test
  public void testSomething() {
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

This has at least one major benefit. You can see that a field is a mock at first glance without reading the setUp method. However, we didn’t save any lines in the setUp method because we need to tell Mockito to instantiate the @Mock annotated fields. This looks really ugly because we are mixing Mockito framework code with our test code. We need to find another way to instantiate the mocks. Luckily, Mockito helps out once again.

Since JUnit4 you can choose specific test runners for test classes. You probably know this because you use it in your TestSuite classes all the time. Anyway, Mockito provides a runner called MockitoJUnitRunner. Using the runner looks like this:

@RunWith( MockitoJUnitRunner.class )
public class SecondPartTest {
 
  @Mock
  Strategy strategy;
 
  Something objectUnderTest;
 
  @Before
  public void setUp() {
    objectUnderTest = new Something( strategy );
  }
 
  @Test
  public void testSomething() {
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

As you can see we could remove the initMocks call in the setUp method and we are nice and clean again. And, that’s how you can get to a clean test using the @Mock annotation. In the next Effective Mockito installment I’ll show you how spies can be used to get to a clean test when you depend on third party libraries .

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

Tags: clean code, Mocking, Mockito, Software craftsmanship, test driven, tips