Question

I have a method under test. Within its call stack, it calls a DAO which intern uses JDBC to chat with the DB. I am not really interested in knowing what will happen at the JDBC layer; I already have tests for that, and they work wonderfully.

I am trying to mock, using JMock, the DAO layer, so I can focus on the details this method under test. Here is a basic representation of what I have.

@Test    
public void myTest()
{
     context.checking(new Expectations() {
          {
               allowing(myDAO).getSet(with(any(Integer.class)));
               will(returnValue(new HashSet<String>()));
          }
     });

    // Used only to show the mock is working but not really part of this test.
    // These asserts pass.
    Set<String> temp = myDAO.getSet(Integer.valueOf(12));
    Assert.assertNotNull(temp);
    Assert.assertTrue(temp.isEmpty());

    MyTestObject underTest = new MyTestObject();
    // Deep in this call MyDAO is initialized and getSet() is called.
    // The mock is failing to return the Set as desired. getSet() is run as 
    // normal and throws a NPE since JDBC is not (intentionally) setup. I want 
    // getSet() to just return an empty set at this layer.
    underTest.thisTestMethod();
    ...
    // Other assertions that would be helpful for this test if mocking 
    // was working.
}

It, from what I have learned creating this test, that I cannot mock indirect objects using JMock. OR I am not seeing a key point. I’m hoping for the second half to be true.

Thoughts and thank you.

Answer 1

From the snippet, I’m guessing that MyTestObject uses reflection, or a static method or field to get hold of the DAO, since it has no constructor parameters. JMock does not do replacement of objects by type (and any moment now, there’ll be a bunch of people recommending other frameworks that do).

This is on purpose. A goal of JMock is to highlight object design weaknesses, by requiring clean dependencies and focussed behaviour. I find that burying DAO/JDBC access in the domain objects eventually gets me into trouble. It means that the domain objects have secret dependencies that make them harder to understand and change. I prefer to make those relationships explicit in the code.

So you have to get the mocked object somehow into the target code. If you can’t or don’t want to do that, then you’ll have to use another framework.

P.S. One point of style, you can simplify this test a little:

context.checking(new Expectations() {{
  allowing(myDAO).getSet(12); will(returnValue(new HashSet<String>()));
}});

within a test, you should really know what values to expect and feed that into the expectation. That makes it easier to see the flow of values between the objects.