SQL gives us a “coalesce” function, which returns the first non-null argument.

This seems to be a common operation in Java too, since Java unfortunately burdens us with the concept of nulls. We have been able to do something similar with Java for some time using a varargs method like this:

    public static <T> T coalesce(T... ts) {
        for (T t : ts)
            if (t != null)
                return t;
 
        return null;
    }
 
    String result = coalesce(somethingPossiblyNull(), somethingElse(), "defaultValue");

(There is a similar method on Guava’s Objects class);

It looks nice and avoids the need for ugly ifs in some places. However, unfortunately it means that somethingElse() would have to be evaluated even if somethingPossiblyNull() returned a non-null value. This is not what we want if these are expensive, so we had to fall back to something less clean.

In Java 8 thanks to lambdas & method references we can do this lazily.

    public static <T> T coalesce(Supplier<T>... ts) {
        return asList(ts)
            .stream()
            .map(t -> t.get())
            .filter(t -> t != null)
            .findFirst()
            .orElse(null);
    }
 
    @Test
    public void should_return_first_non_null_value() {
        Person nullName = new Person(null);
        Person bob = new Person("bob");
        Person barbara = new Person("barbara");
 
        assertEquals("bob", coalesce(nullName::name, bob::name, barbara::name));
    }

Here we pass in suppliers for the values rather than the values themselves. First we invoke the supplier to get the value, then filter it out if it is null (as we are looking for the first non-null value), and then return the first matching – meaning that we do not look farther through the list of passed values than we need to.

We can demonstrate that we do not invoke unnecessary methods

    @Test
    public void should_be_lazy() {
        Person bob = new Person("bob");
        Person angryPerson = new Person("angry") {
            @Override public String name() {
                fail("Should not have asked for the angry person's name");
                return "angry";
            }
        };
 
        assertEquals("bob", coalesce(bob::name, angryPerson::name));
    }

Here we never invoke the name method on angryPerson because bob had a non-null name.

If we want to do something more complicated than calling a Supplier-like method we can always use lambdas

    @Test
    public void should_be_able_to_use_lambdas() {
        assertEquals("bob", coalesce(() -> new Person("bob").name(), () -> new Person("barbara").name()));
    }

Or, if people ever stop returning nulls all over the place then you can of course do the same with Optionals

The AnotherSupplier interface is just to work around Type Erasure terribleness.

    @Test
    public void should_be_able_to_use_optionals() {
        assertEquals("bob",
            coalesce(
                () -> Optional.<String>empty(),
                () -> Optional.of(new Person("bob").name()),
                () -> Optional.of(new Person("barbara").name())
            ).get()
        );
    }
 
    interface AnotherSupplier<T> extends Supplier<T> {}
 
    public static <T> Optional<T> coalesce(AnotherSupplier<Optional<T>>... ts) {
        return asList(ts)
                .stream()
                .map(t -> t.get())
                .filter(t -> t.isPresent())
                .findFirst()
                .orElse(Optional.<T>empty());
    }

By the way – C# provides an operator for doing this

Code on github

Today someone asked how to verify that only your stubbed interactions occur, and no others (when using Mockito).

I have heard this asked this quite often, especially by people used to JMock where mocks are strict by default.

I’d be interested in knowing if there’s an out of the box way of doing this.
The normal way to do this is to verify all the calls you expect to happen and then verify no more interactions occur.

This often seems like unnecessary duplication with the “when” stubbing. You end up with something like

    @Test
    public void exampleOfRedundantVerify() throws Exception {
        Duck duck = mock(Duck.class);
        when(duck.quack()).thenReturn("quack");
        when(duck.waddle()).thenReturn("waddle");
 
        duck.quack();
        duck.waddle();
 
        //Why do we need to do this?
        verify(duck).quack();
        verify(duck).waddle();
 
        verifyNoMoreInteractions(duck);
    }

If you omit the two verify lines then the test will fail, despite us stubbing quack with “when”. It would be nice to remove this duplication.

Now, at this point someone will probably point out that often verifyNoMoreInteractions, and even multiple verifications in a test can be a sign of an inflexible test that is easy to break with minor implementation changes. However, sometimes you really do want to assert that a collaborator is only used in a specific way. You might also temporarily want the mocks to be more vocal about how they are used, in order to help diagnose why a test is failing.

So how can we make this better with Mockito? Mockito provides an Answer.
To implement Answer you simply have to implement

    public T answer(InvocationOnMock invocation) throws Throwable

This is called when you invoke a method on a mock.

Answer is an interface that Mockito provides to allow you to specify the response to a method invocation on a Mock. It gives a bit more power than simply returning a value. For instance you can use it to capture method parameters passed to stubbed method calls for later assertions.

Answer is useful for solving this problem because we can specify a default Answer that a mock will use whenever a method invocation has not been stubbed. In our case we want the test to fail, so we can simply throw an Exception with some information about the unexpected invocation.

Here’s what we can enable

    @Test
    public void exampleStubbedAll() throws Exception {
        Duck duck = strictMock(Duck.class);
        when(duck.quack()).thenReturn("quack");
 
        verifyNoUnstubbedInteractions(duck);
 
        duck.quack();
    }
 
 
    @Test(expected = NotStubbedException.class)
    public void exampleNotStubbedAll() throws Exception {
        Duck duck = strictMock(Duck.class);
        when(duck.quack()).thenReturn("quack");
 
        verifyNoUnstubbedInteractions(duck);
 
        duck.quack();
        duck.waddle();
    }

Here the first test only performs stubbed operations on the mock, so passes. The second test calls an unstubbed method and an Exception is thrown.

How is it implemented? First we create a static method to create ourselves a mock. The second argument here is the default answer, Mockito will invoke the “answer” method on this handler for every unstubbed invocation.

    public static <T> T strictMock(Class<T> cls …

As with try-as-expression, there are many other language features we can simulate with Lambdas.

Another example is removing the cast commonly needed with instanceof. Kotlin has a nice feature called smart casts, which allows you to do

    if (x instanceof Duck) {
        x.quack();
    }

Where x is “casted” to Duck within the block.

I previously blogged how to simulate this in older Java using dynamic proxies.

Now in Java 8 you can do it in a slightly less terrible way, and also make it an expression at the same time.

    @Test
    public void should_return_value_when_input_object_is_instance() {
        Object foo = "ffoo";
 
        String result = when(foo).instanceOf(String.class)
                .then(s -> s.substring(1))
                .otherwise("incorrect");
 
        assertEquals("foo", result);
    }

More examples and implementation on github.

I’ve been familiarising myself with the new Java 8 language features. It’s great how much easier it is to work around language limitations now that we have lambdas.

One annoyance with Java is that try blocks cannot be used as expressions.

We can do it with “if” conditionals using the ternary operator.

    String result = condition ? "this" : "that";

But you cannot do the equivalent with a try block.

However, it’s fairly easy now that we have lambdas.

    @Test public void should_return_try_value() {
        String result = Try(() -> {
            return "try";
        }).Catch(NullPointerException.class, e -> {
            return "catch";
        }).apply();
 
        assertEquals("try", result);
    }

Code and more tests on github