Start testing your Java with Groovy

[Matthew Taylor]

Let's look at an example of how using Groovy to test your existing Java code could cause significant gains...

So you have this nasty interface that needs to be mocked and injected into your class under test:

ComplicatedInterface.java

import java.sql.ResultSet;

public interface ComplicatedInterface {

    void methodOne(ResultSet rs, String s);

    void methodTwo(
        String one,
        String two,
        String three,
        String four,
        String five
    );

    int methodThree(int i);
}    

In order to create a mock or stub object for this, you'll need to implement three methods, one with a ResultSet, and one with several parameters. Bleck.

The class under test is called Worker:

Worker.java

public class Worker {

    private ComplicatedInterface ci;

    public boolean uglyMethod() {
        int number1 = DumbUtils.generateNumber(ci);
        int number2 = DumbUtils.generateNumber(ci);
        return (number2 > number1);
    }

    public ComplicatedInterface getCi() {
        return ci;
    }

    public void setCi(ComplicatedInterface ci) {
        this.ci = ci;
    }
}

... and all we really want to test is that uglyMethod calls some static utils class with the given interface implementation twice, then compares the results properly, returning true if the second number is greater than the first. For simplicity's sake, we'll make our static utils as dumb as possible:

DumbUtils.java

public class DumbUtils {

    public static int generateNumber(ComplicatedInterface ci) {
        return ci.methodThree(7);
    }

}

So if you want to test Worker.uglyMethod using Java, it would be messy. You'd have to create a mock class that implements the ComplicatedInterface, and it would have all those nasty method implementations. I know you've seen some interfaces with 17 required methods, each one more complicated than the other. I'm making it even simpler just by having three.

But let's not even bother to do this with Java. Let's do it the easy way: with Groovy...

WorkerTests.groovy

class WorkerTests extends GroovyTestCase {

    Worker worker

    void setUp() {
        worker = new Worker()

    }

    void test_ReturnsTrue_WhenNum2GreaterThanNum1() {
        def count = 0
        def mockMethodThree = { int i ->
            return count++
        }
        worker.ci = [methodThree:mockMethodThree] as ComplicatedInterface

        def result = worker.uglyMethod()
        assertTrue 'returned false when num2 > num1', result

    }

    void test_ReturnsFalse_WhenNum2LessThanNum1() {
        def count = 0
        def mockMethodThree = { int i ->
            return count--
        }
        worker.ci = [methodThree:mockMethodThree] as ComplicatedInterface

        def result = worker.uglyMethod()
        assertFalse 'returned true when num2 < num1', result
    }
}

In case you missed it, the magic line is

worker.ci = [methodThree:mockMethodThree] as ComplicatedInterface

We know the class under test needs to call DumbUtils.generateNumber, passing in the ComplicatedInterface. In DumbUtils, the interface's methodThree is called to return an int value. So we've created a mock method in the form of a closure. In the first test, it starts at 0 and returns one greater on each call. In the second test, it goes one lesser. We are using this closure within a map to provide an implementation of the ComplicatedInterface's methodThree requirement. And because we are telling Groovy that we want to treat this map "as" a ComplicatedInterface, it takes care of mocking out all the rest of the interface's implementation. Then that mock is injected into the class under test and is available during the test run.

This is a common antipattern in enterprise applications, and it can be frustrating to keep the tests focused on the code under test, instead of mocking out the state of the application to prepare for the test. Groovy can help provide shortcuts during testing that makes your tests more expressive and help you focus on the real task of your tests.

[Marc Peabody]

I love this post. This testing trick is something I've used quite a bit.

In some cases, this can eliminate the need for an interface declaration altogether. Spring's popularity has led to an interface being created for nearly every bean even though the only two implementations are typically the actual implementation and the test implementation. Eliminating the need for the test implementation eliminates the need for a separate interface declaration (why have an interface with only one class that implements it?). That cleans up the package noise in my projects quite a bit and I like that.