Aslak Hellesoy's uncommon sense - Static or Dynamic Mock: A brief comparison.

Static or Dynamic Mock: A brief comparison.

[ Aslak Hellesoy ] 01:49, Wednesday, 21 January 2004

Crazybob is Mocking. It struck me that his tests could have been even shorter and IMO more readable had he used a mock library based on dynamic proxies (like JMock). The static way (Bob's example with minor corrections):

    // Lines of code in the body: 10
    // Number of characters in the body (minus leading indentation whitespace): 274
    // (Not counting the MockServletConfig baseclass, which also has to be coded).
    public void testGetInitParameterWithStaticcMock() {
         final String expectedName = "foo";
         final boolean[] called = new boolean[1];
         new MyServlet().init(new MockServletConfig() {
              public String getInitParameter(String name) {
                   called[0] = true;
                   assertEquals(expectedName, name);
                   return null;
               }
          });
         assertTrue(called[0]);
     }

The dynamic way:

    // Lines of code in the body: 4
    // Number of characters in the body (minus leading indentation whitespace): 235
    public void testGetInitParameterWithDynamicMock() {
         Mock mockServletConfig = new Mock(ServletConfig.class);
         mockServletConfig.expectAndReturn("getInitParameter", C.args(C.eq("foo")), null);
         new MyServlet().init((ServletConfig) mockServletConfig.proxy());
         mockServletConfig.verify();
     }

(Some of you might argue that size isn't everything - I disagree of course - but if you have opinions about other drawbacks/benefits of each approach, let's hear it!)

IMO the dynamic way is much more readable and elegant. I've used CrazyBob's approach in other mock tests and I find the, in this example, "called" array obscures the test. It doesn't, at least to me, feel natural.

A two minuts glance at the examples for JMock (http://jmock.codehaus.org/docs.html#tutorials) is what it took to learn enough JMock to understand the example.
If we mock a lot we would anyway have to learn a mechanism for mocking (either CrazyBobs, JMocks or your own), just like we learned the mechanism for Unit testing.

My problem with static mocking is that you often end up with a lot of "empty" mock classes.

However, refactoring doesn't seem as straight forward with JMock (if you use the approach above) as with static Mocks. It's harder to get Eclipse or IDEA to help you when renaming the getInitParameter() method.

Are there more refactoring friendly ways to use JMock to do the same test?

--Jeppe Cramon, January 21, 2004 01:23 PM

My good colleague Morten Frederiksen, pointed me to EasyMock (http://www.easymock.org), which supports a more refactoring friendly mock testing.

Below is a sample of how to do the same test.

// Create a nice control so that easymock doesn't complain if other methods are called. If we instead use createControl() it will complain if other methods, than those you record, are called. With this you can avoid the NotSupportedException from CrazyBobs example.

MockControl control = mockControl.createNiceControl(ServletConfig.class);
ServletConfig mockServletConfig = (ServletConfig) control.getMock();

// After having created the control, it will automatically be in record mode.

// Here's one way to test a method call and expected return value
mockServletConfig.getInitParameter("foo");
control.setReturnValue(null);

// Here's an alternative way to do it (you should only use one of them in this sample)
control.expectAndReturn(mockServletConfig.getInitParameter("foo"), null);

// Change to replay mode (test mode)
control.replay();

// Test
new MyServlet().init(mockServletConfig);

control.verify();

--Jeppe Cramon, January 21, 2004 02:53 PM

Oh yeah, that's a lot more "natural." ;)

My point is not about the length. My point is about flexibility (i.e. doing more than dumb "expect and return" logic).

Hani has already ranted about this before, so I'm not going to bother repeating:

http://www.jroller.com/page/fate/20030610

--Bob Lee, January 21, 2004 04:00 PM

I agree with Aslak. It is more elegant and you can have constraints on the arguments to the mocked call to make sure that the call is called correctly.

Regarding the Hani's post - I agree with some of his concerns. I use mocks only when I need to cross layers and where I don't have to depend upon the values set up another call to return the values of the current call.

--Venkat, January 21, 2004 04:40 PM

Jeppe: Eclipse can refactor method names in strings, and I'm sure IdeaJ can as well, but it's a good idea to check them in the preview. JMock exposes all the information that a refactoring tool would need to support the mocking API. Eclipse 3 will allow plugins to hook into the refactoring engine. One of our longer term aims is to write a plugin for Eclipse 3 that safely applies method renames and other refactorings to JMock expectations.

Bob: Both jMock and the earlier DynaMock API expose extension points that allow the programmer to insert custom testing behaviour if the syntactic sugar is not expressive enough. I don't know why Hani ignored that; perhaps he didn't find the documentation on the Mock Objects website, didn't look at the unit tests, or didn't want to allow reality to spoil the humour of his spittle-spraying rant.

--Nat Pryce, January 22, 2004 08:43 PM

pissing dripping wet see through bikinis see throughwet t-shirt wet t-shirt contest t-shirts wet t-shirts t-shirt 70 t-shirts funny t-shirts caught wet pants underwear mens underwear men in underwear boys underwear mens underwear piss peeing girls peeing women peeing pee watersports wet t-shirt wet wet pussy wet t shirt wet see through bikinis wet t-shirt contest wet panties wet t-shirts wet t wet shirt wet tshirt wet girls wet t shirts wet t shirt contest wet pants

--pol, August 13, 2004 08:28 PM

--roma, August 13, 2004 08:33 PM

--alex, August 14, 2004 02:04 AM