Mockito-like automocking and optional autowiring in JMock

I’m running my little TDD course again, and (as usual) it’s given rise to another small idea to make unit testing easier: provide Mockito-like automocking (using a @Mock annotation), and in addition perform autowiring of all mocks into the class under test.

Now, to be honest, the difficult bit, automocking, is already in the JMock codebase, but as of this writing it’s still not been released (come on guys!). So I’ve just taken that code and tweaked it to also support this idea of autowiring.

Here’s what it looks like in code:

public class JUnitRuleMockery2Test_autoWiring {

    public JUnitRuleMockery2 context = 

    private Collaborator collaborator;

    private Collaborating collaborating;

    public void setUp() throws Exception {
        collaborating = (Collaborating) context.getClassUnderTest();
    public void checkAutoWiring() {
        assertThat(collaborating, is(not(nullValue())));
        assertThat(collaborating.collaborator, is(not(nullValue())));

Where to get this code? Well, since I’ve now blogged about a couple of utilities, I thought I’d upload them to this new github project. There’s the stuff from those posts and this one, as well as a couple of other goodies. Just pull it down and build with Maven.

As ever, feedback welcome!

About these ads

Posted on July 11, 2012, in Uncategorized and tagged , , , . Bookmark the permalink. 6 Comments.

  1. Would you like to help us get the next release out?

  2. What would you say to going one step further? what about automagically guessing what the collaborators of a class under test are, then instantiating and injecting them? (The automagic would use some metadata which is provided by the applications anyhow.)

    I materialiazed this and some more ideas some time ago in POC project called komarro ( What do you think?

    • I prefer to see the collaborators enumerated in the test, using @Mock. After all, tests help document the system… one doesn’t want too much magic, just enough to remove boilerplate/noise.

      Still, it’s nice to see some convergence of ideas between your komarro project and the bit of work that I did. However, unlike seemingly most people, I don’t like Mockito as much as JMock (and this is having used the former for a year on an earlier project).

      Thanks for the input, though… all interesting stuff

      • Dan,

        I see what you mean, but don’t you think that enumerating the collaborators explicitly couples your test to implementation details? In other words: imagine you write some javadoc to document a method that obtains data from a datasource. In javadoc of such a method I would probably not specify explicitly what is the name and the exact method of its collaborator. I may, however, point out that the method gets data from a datasource (indirect input parameter) and then performs some calculations on it.

        Just for clarification, I’m not trying to claim that what you said is wrong or not – my opinion on that is quite fuzzy too. I would like to know if your application really benefits from having the mocks enumerated (or maybe you found it to cause problems at some stage).


  3. @marekdec,
    I think that if you use interfaces than your test should also contain a datasource which is in the relevant layer of abstraction as your unit under test. Additionally I think JMock derives from the school of thought that thinks that the main concern is the “conversation” between an object and its collaborators and that is extremely important to be out in the open.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 298 other followers