Testing Delegate Methods

We had an interesting discussion the other day: should we write unit tests for delegate methods, that is, methods that only delegate the call to a delegate object? Here’s an example of such a method:

I said I did not see much value in a unit test for this method as all the test could do is verify whether the do()  method of the mocked delegate object was called. Instead of testing behaviour, we would test the wiring which is close to trivial in this case and should be tested implicitly as part of an integration test involving the delegate object and the main object.

Some of my colleagues disagreed with me. Their argument was that a unit test would detect changes in the delegate call and indicate the intended usage of the delegate object. They were concerned an incorrect wiring could be introduced without a unit test. And this unit test would be cheap to write.

I did not find any of these arguments very convincing – and I’m in good company: the JUnit team’s FAQ webpage has a section on Best Practices which comments on testing delegate methods. You can read it here. Thank you, J. B. Rainsberger!

Headless Testing with TestFX

Jérome Cambon wrote a nice introduction to TestFX and how to enable the headless mode using Monocle.

I tried to reproduce the steps he described for running my TestFX GUI tests in headless mode from Eclipse so I can keep using my mouse while they are running. The crux is setting the VM arguments in Eclipse. First, I tried to set

in the VM arguments section of the JRE tab in my Maven run configuration:

Maven run configuration in Eclipse

This did not work. I could still see the TextFX robot move the mouse cursor on my screen.

I had to specify the VM arguments using Maven’s ‘argLine’ parameter:

Maven argLine parameter

If anyone knows why setting the VM arguments in the run configuration did not work, please let know.

How to Make Unit Tests more Likeable

What are these unit tests good for? Are we testing Mockito?

This is what a colleague asked another colleague a couple of days ago. He was referring to some rather complicated and long unit tests that used a lot of mocks and verify statements. I knew what he was talking about since I had seen quite a few tests like that myself.

Whenever a JUnit test method has more than ten lines or so, I get suspicious (and sometimes start crying). Add a few ArgumentCaptors and I’m done with that test. If I’m supposed to fix a test like that, I tend to give up quickly and rather delete the test method than try to understand what is being tested and why it fails.

A good test, however, makes me smile. It’s short, concise and readable because it follows the arrange, act, assert principle. It uses Mockito’s fluent API if it uses Mockito at all. That’s anyString()  instead of Mockito.anyString()  and times(2)  instead of VerificationModeFactory.times(2) (which is Mockito’s internal API btw). And mocks, stubs, spies, and dummy objects are set up in the @Before  method instead of every test method. This saves a lot of boilerplate code and makes me want to fix the test if it breaks.