A couple of days ago, a co-worker came by with an interesting problem. His unit test class was failing, with a mock saying that it got more calls to a certain method than it had been set up to expect.
The odd thing was, the test class we were looking at didn’t declare any mocks!
The failing test class passed when run by itself, failing only when run with the rest of the module’s unit tests…
The problem turned out to be that a test class that ran earlier in the test run was injecting a mock into a singleton and not cleaning up after itself. The singleton was later used by the failing test, which unwittingly made use of the mocked guts of the singleton, resulting in the unmet expectations.
The offending test just needed to reset the guts of the singleton back to its normal, non-mocked value in its @After or @AfterClass method.
It seems to me it would be even better to implement the singleton using a factory, to avoid such side-effects popping up in the future (see StartupSvcFactory: why go to the bother? for some discussion about factories and singletons). True, there’s the extra conceptual overhead of one more (factory) class and two more interfaces — but I think the resulting cleanness of the test code makes it worth it, at least if you ever need to mock what the singleton provides (as we did in this example).