Unit Testing Guide

Using Mockito to Unit Test real objects with 'Answer'

2010-03-03T23:14:00.000-08:00

As a follow up to my previous post, this is how to Unit Test with JUnit and Mockito if a void method was called instead to move the User.

Take this code as an example:


public void handleMoveForwardRequest(String[] command)
{
        // userId should be the first element
        User user = getUser(command[0]);
        movement.moveUserForward(user);
        // this depends on the socket server API for the exact call
        extension.sendTheResponse(command, user, user.getCurrentLocation());
}

This code is a little unrealistic, but humour me for this example. Assume that we can pass in a mocked Movement with a setter. We are going to use Mockito's 'answer' call to update the location for the User (which cannot be mocked). They suggest not to use it, but we aren't testing the Movement class.

//Assume that the mock objects were previously instantiated
@Test
public void canMoveForward()
{
    String[] command = new String[] {"123", "Forward"};
    handler.setMovement(mockMovement);

    // use hamcrest matchers for the object we're expecting
    when(mockMovement.moveUserForward((User) anyObject()))
.thenAnswer(new Answer() { Object  answer(InvocationOnMock invocation) 
{
 Object[] args = invocation.getArguments();
 User user = (User) args[0];
 user.setLocation(user.getCurrentLocationX() + 1, user.getCurrentLocationY());
 return "called with arguments: " + args; 
} 
});

    User user = getUser(command[0]);
    handler.handleMoveRequest(command);
    verify(mockExtension).sendTheResponse(command, mockUser, user.getCurrentLocation());
}

When 'moveUserForward' is called a new 'Answer' is created. It updates the location of the user to some arbitrary value. In this case we added 1 unit to the X location. Our test will pass because the User is a static reference to that object. The location actually is updated for the object that the SUT gets, and the object our test checks for.

This can seem complicated at first, and it probably isn't necessary because most TDD code is cleaner than this. However, in complicated systems with legacy code you may stumble across a similar situation.

Mockito Mocks Rock For Service Requests and Responses

2010-02-25T19:43:00.000-08:00

My mocking framework of choice when Unit Testing with JUnit is Mockito. You will hear me preach about readability and, used in conjunction with hamcrest matchers, Mockito achieves that.

Recently I was tasked with testing server side code that could handle requests and sent responses to a socket server. This is not an easy job as most socket servers have their own API which is untouchable. One option is to create an accessor class for the class you are testing and overwriting the method calls. Really not that friendly, but I will post about that option in the future. The second option is using Mockito and developing code that allows Dependency Injection on the socket servers main extension class. If someone requires more details on how to do that, please ask and I will post on that.

Using Mockito you can verify a response was sent when a request was handled by the class with specific parameters. Take this code as an example (obviously I left this as ambigous as possible and the code is unrealistic):


public void handleMoveRequest(String[] command, User user)
{
    if (command[0] == "Forward")
    {
        user.moveForward();
        // this depends on the socket server API for the exact call
        extension.sendTheResponse(command, user, user.getCurrentLocation());
    }
    else
    {
        user.moveBackwards();
        extension.sendTheResponse(command, user, user.getCurrentLocation());
    }
}

The only way to test the result of the communication with the socket server (from a Unit Testing standpoint) is to Mock the socket server's extension and verify the parameters in the response. Here is how Mockito allows us to do that:


// Assume that the mock objects were previously instantiated
@Test
public void canMoveForward()
{
    String[] command = new String[] {"Forward"};
    when(mockUser.getCurrentLocation()).thenReturn("1, 1");
    handler.handleMoveRequest(command, mockUser);
    verify(mockUser).moveForward();
    verify(mockExtension).sendTheResponse(command, mockUser, mockUser.getCurrentLocation());
}

There are many who say there should be one test (assertion) to each test case. Really this is one behaviour that requires 2 checks. If we made separate tests, we would really be duplicating code.

I leave you with this... what if we wanted to test with a real user? The method 'getCurrentLocation' would probably return a different result after 'moveForward' was called. We can also use Mockito to help with that. I will show how in the next post.

Unit Testing: Naming Conventions

2010-02-23T20:36:00.000-08:00

One of the most important aspects of Unit Testing is readability. If your tests are properly named, as well as your variables, it leads to self-documenting code that is easy to follow. It is common practice in TDD for the progammer to write their own tests. In the companies that I have worked for, it is common for many developers to work on the same code base. If there is no standard or guideline for naming conventions, trying to decipher the code can be a headache.

Naming Conventions
I will always stress the importance of testing the behaviour of the code rather than the implementation. This starts with naming your test cases appropriately. Take the following code as an example:


public Connection getConnection(String connectionName)()
{
    Connection connection;

    switch(connectionName)
    {
        case "PrimaryDb":
            connection = ConnectionType.ONE;
        case "SecondaryDb":
            connection = ConnectionType.TWO;
        default:
            connection = null;
    }

    return connection;
}

Now let's analyse the following test case names:

getConnection_Can_Get_A_Database_Connection
getConnection_canGetTheConnectionForDatabase1
canGetTheConnectionForThePrimaryDatabase

From my perspective, the last option is the best one. The first option says nothing about the database we are trying to get a connection for. I also prefer not to over use underscores when separating words. Names become too lengthy. The second option reads nicer than option 1, but the method being tested is indicated. For maintaining code, this can be overkill. If you're writing your tests while you're coding you know how often refactoring occurs. It is a pain to have to manually change the name of each of your tests when changing the name of a method. Most IDE's have a refactoring option which automatically rename all references. The third option specifies the behaviour we are testing and uses camel case so that it is easy to read without being too lengthy. You may need to start each test case with "test" depending on the framework you're using. Most xUnit frameworks allow an "@Test" annotation.

Naming Variables
Current IDE's will most likely be equipped with auto-complete features. They can save a huge amount of keystrokes and if you are writing in a losely typed language like PHP, can help ensure you are not accidentally creating new variables. As I mentioned previously, self documenting code is an extremely important aspect of Unit Testing and variable names are part of that. Take the following example of a test case:


@Test
public void canReduceTheAmountOfFundsInASavingsAccount()
{
    account = new Account(AccountType.SAVINGS);
    account.setFunds(50);
    account.subtractFunds(35);
    assertEquals(15, account.getFunds());
}

The test is very easy to follow because the tester used descriptive variables and an Enum to specify the type of account. I have seen people take shortcuts and may name their variables "a" or "act". That may save a couple keystrokes, but it is much harder to follow when revisiting failed test cases.