How to unit test callback logic?

Question

More complete question is, given a dependency that expects a callback as a parameter, how do I write a unit test that covers the callback logic and still manage to mock up the dependency?

public class DoStuff {
    public void runThis(Runnable callback) {
        // call callback
    }
}

public class ClassUnderTest {
    private DoStuff stuffToDo;

    public void methodUnderTest() {
        this.stuffToDo.runThis(/*a runnable with some logic*/)
    }
}

In the example above, I would mock stuffToDo since I should verify calls and mock outputs of method calls. However, mocking runThis results in the callback logic not being tested. Furthermore, callback logic seems like it should be private so I wouldn't expect to test it directly; perhaps that is a misconception on my part.

Since callbacks are used rather extensivly, I would expect there to be a common method for testing them but I haven't found it.

Does the callback only need to be tested in this context? If so, why not simply write tests for the various callbacks you plan on passing, which express your expectation of their results? Am I missing something? — Jonah, Aug 22 '11 at 13:29
Have you tried using CountDownLatch like in this example: http://stackoverflow.com/a/3802487/2301224 — Baker, Jan 05 '16 at 03:50

score 12 · Accepted Answer · answered Aug 22 '11 at 13:31

You can't in a single test. If you mock something, its mocked, meaning it can only verify arguments and simulate return values (that you configure in the test).

Indeed, the entire point of mocking something is to test what uses the mock in isolation. If you want a unit test of DoStuff, you don't want to have to worry about using some callback implementation that might or might not be working. You mock the callback so you don't have to worry about it.

You can still have good tests by testing the callback code in isolation, and testing the callback user in isolation (using a mock for the callback) and perhaps by throwing an integration test in for good measure, where you use the fully configured component as a whole.

score 1 · Answer 2 · answered Aug 22 '11 at 13:32

1

Here basically you want to test the class DoStuff. That means you need to unti-test all the methods inside DoStuff, right?. So in this case, what you need to do is, instead of mocking stuffToDo itself, inject a mocked Runnable into stuffToDo. And then check whether your runnable was successfully executed or not.

But if you do have other functionalities in the class, you may have separate test and mock them out.

answered Aug 22 '11 at 13:32

Suraj Chandran

24,433
12
63
94

1

I want to test ClassUnderTest which takes DoStuff as a dependency. – Andrew White Aug 22 '11 at 14:40

Michael Hays · Answer 3 · 2011-08-22T16:47:48.097

In your particular case, it sounds like you've already tested DoStuff (or don't care anymore since it is mocked) and now are specifically unit-testing a specific Runnable you've designed. In this case, callback sounds like exactly what you want to be testing, in the same manner someone might want to specifically unit-test a database strategy or in-memory strategy directly.

If this is what you are attempting, either you can test it in a black box, exercising it through ClassUnderTest as best as you can. Or you can create a testing harness on your particular Runnable. If you are releasing this code and don't want to make your testing harness reachable, you can make the test harness methods private and share its details specifically with your unit test assembly.

Look here for information about how to make friend assemblies. I typically sign my unit test code so that I don't have to muck with a command line compiler. I suppose it depends on your build environment.

No, ClassUnderTest is the class to be tested. I'm mocking DoStuff. — Andrew White, Aug 22 '11 at 14:41
I modified the class name to reflect this. It doesn't affect the answer. — Michael Hays, Aug 22 '11 at 16:48

score 0 · Answer 4 · edited May 27 '16 at 14:34

0

If your using EasyMock, you can use andStubAnswer to call the runnable.

doSomethingMock.runThis(runnable);
expectLastCall().andStubAnswer(new IAnserable<Void>() {
   Runnable runnable = (Runnable)getCurrentArguments()[0];
   runnable.run();
   return null;
});

I imagine other mocking frameworks contain something similar.

edited May 27 '16 at 14:34

hcpl

17,382
7
72
73

answered Aug 22 '11 at 19:45

Michael Krussel

2,586
1
14
16

score 0 · Answer 5 · answered Aug 23 '11 at 05:40

0

How about a fake DoStuff that just invokes the Runnable unconditionally ?

Then you just sense for the effects - changes that should be observed if your callback was executed.

answered Aug 23 '11 at 05:40

Gishu

134,492
47
225
308

How to unit test callback logic?

5 Answers5