Some while back I was preparing a presentation on mocking and testing frameworks for Java. As part of the aim was to demonstrate some real, running code, I ended up spending quite some time copying, pasting, extending and correcting various examples gleaned from readmes, Javadoc, Wiki pages and blog posts. Since then, this codebase has been extended with various new features I've come across, and I've often referred to it for experiments, as a helpful reference, and suchlike. I imagine this kind of "live" reference could also be useful to others, so I thought I'd share it. Mock Braindump By way of introduction, here first a braindump of various points of interest related to the frameworks in the sample. Don't expect a detailed overview or comparison - there are plenty out there - and for specific questions about the working of the frameworks please refer to their documentation. Mockito or EasyMock? EasyMock and Mockito are the de facto standard mocking frameworks out there at present. Their feature sets are more-or-less identical, and if one of them comes up with something new you can be pretty sure it'll be in the next version of the other. Personally, I have to say that I find Mockito's syntax just that little bit nicer and more intuitive. The fact that you don't explicitly have to switch to replay mode is handy, and for things like spy (for partial mocks) or InOrder (for ordered expectations) the syntax is simply more elegant. More fundamentally, the emphasis on stubbing rather then laboriously verifying calls to mocks was, to me, a very useful and justified distinction. Having said all that, it might well stike you as paradoxical that I still mainly use EasyMock on a day-to-day basis: force of habit and the fact that the projects I'm working on started out with EasyMock sees to that. The advantages I believe Mockito has are not sufficiently large to justify the switch. Statics, locals and finals: TDD's final frontier? "To boldly go...where no mocking framework has gone before" seems to be the mission of both Jmockit and JEasyTest. public final class ServiceA { public void doBusinessOperationXyz(EntityX data) throws InvalidItemStatus { List<!--?--> items = Database.find("select item from EntityY item where item.someProperty=?", data.getSomeProperty()); BigDecimal total = new ServiceB().computeTotal(items); data.setTotal(total); Database.save(data); } } public static final class ServiceB { ... The challenge: to be able to unit test this class, specifically the find and save calls on Database and the computeTotal call on the new ServiceB instance. Using convential mocking this is nigh-on impossible:
  • find and save are static
  • ServiceB is a final class and thus can't be mocked
  • even if it could be, the ServiceB instance called is created in the code under test
My immediate reaction? If this is the kind of code you're supposed to test, you have other problems! Yes, of course it's an artificial example specifically chosen to highlight cases normal mocking can't deal with. But even if the real code you're having trouble with contains only one of these cases, I'd consider trying to refactor the code before looking for a different test framework. Dependency Injection may have become a bit of a religion, but it is not so widespread for nothing. For code that's doing DI, the standard mocking frameworks are almost always sufficient. But even if one perhaps shouldn't try to unit test the example, could one? For details of how Jmockit and JEasyTest approach this issue, and examples of (amongst others) testing concurrent code and JUnit 4.7 rules, see the original blog post. For those interested, the sample code is available here.