Question

Assume the following setup:

interface Entity {}

interface Context { 
     Result add(Entity entity);
}

interface Result {
     Context newContext();
     SpecificResult specificResult();
}

class Runner {

    SpecificResult actOn(Entity entity, Context context) {
           return context.add(entity).specificResult();
    }
}

I want to see that the actOn method simply adds the entity to the context and returns the specificResult. The way I’m testing this right now is the following (using Mockito)

@Test
public void testActOn() {
    Entity entity = mock(Entity.class);
    Context context = mock(Context.class);
    Result result = mock(Result.class);
    SpecificResult specificResult = mock(SpecificResult.class);
    when(context.add(entity)).thenReturn(result);
    when(result.specificResult()).thenReturn(specificResult);
    Assert.assertTrue(new Runner().actOn(entity,context) == specificResult);
}

However this seems horribly white box, with mocks returning mocks. What am I doing wrong, and does anybody have a good “best practices” text they can point me to?

Since people requested more context, the original problem is an abstraction of a DFS, in which the Context collects the graph elements and calculates results, which are collated and returned. The actOn is actually the action at the leaves.

Answer 1

It depends of what and how much you want your code to be tested. As you mentionned the tdd tag, I suppose you wrote your test contracts before any actual production code.

So in your contract what do you want to test on the actOn method:

• That it returns a SpecificResult given both a Context and an Entity
• That add(), specificResult() interactions happen on respectively the Context and the Entity
• That the SpecificResult is the same instance returned by the Result
• etc.

Depending on what you want to be tested you will write the corresponding tests. You might want to consider relaxing your testing approach if this section of code is not critical. And the opposite if this section can trigger the end of the world as we know it.

Generally speaking whitebox tests are brittle, usually verbose and not expressive, and difficult to refactor. But they are well suited for critical sections that are not supposed to change a lot and by neophytes.

In your case having a mock that returns a mock does look like a whitebox test. But then again if you want to ensure this behavior in the production code this is ok.
Mockito can help you with deep stubs.

Context context = mock(Context.class, RETURNS_DEEP_STUBS);
given(context.add(any(Entity.class)).specificResult()).willReturn(someSpecificResult);

But don’t get used to it as it is usually considered bad practice and a test smell.

Other remarks :

• Your test method name is not precise enough testActOn does tell the reader what behavior your are testing. Usually tdd practitioners replace the name of the method by a contract sentence like returns_a_SpecificResult_given_both_a_Context_and_an_Entity which is clearly more readable and give the practitioner the scope of what is being tested.

• You are creating mock instances in the test with Mockito.mock() syntax, if you have several tests like that I would recommend you to use a MockitoJUnitRunner with the @Mock annotations, this will unclutter a bit your code, and allow the reader to better see what’s going on in this particular test.

• Use the BDD (Behavior Driven Dev) or the AAA (Arrange Act Assert) approach.

For example:

@Test public void invoke_add_then_specificResult_on_call_actOn() {
    // given
    ... prepare the stubs, the object values here

    // when
    ... call your production code

    // then
    ... assertions and verifications there
}

All in all, as Eric Evans told me Context is king, you shall take decisions with this context in mind. But you really should stick to best practice as much as possible.

There’s many reading on test here and there, Martin Fowler has very good articles on this matter, James Carr compiled a list of test anti-patterns, there’s also many reading on using well the mocks (for example the don’t mock types you don’t own mojo), Nat Pryce is the co-author of Growing Object Oriented Software Guided by Tests which is in my opinion a must read, plus you have google 😉