Groovy Mocks

Groovy supports “natively” mocks and stubs. I will not go into this topic as it is quite well covered here. However, basically what you can do is:

/* the invocation params are passed to the closure */
mock.demand.real_method(params) { params -> 
    /* some code that will be executed when method is called */
}
mock.use {
  /* code that uses the mock */
}

Exactly the same can be done with stubs. Groovy in Action explains the conceptual difference between mocks and stubs:

Stubs enable your CUT [n.b. class under test] to run in isolation and allow you to make assertions about state changes of the CUT. With mocks, the test focus moves to the interplay of the CUT and its collaborators. What gets asserted is whether the CUT follows a specified protocol.

There are other behavioral differences between mocks and stubs, so I would encourage you to get a copy of GinA for more details. The advantages and ease of usage are evident. As for TDD adepts I think they already know that using a dynlang will ease their life.

Another very cool feature of Groovy is the possibility to define properties. So, instead of having to write a java bean like:

class JavaBean {
  private String name;

   public String getName() { return name; }

   public void setName(String n) { name = n; }
}

you just need to write:

class GroovyBean {
  String name;
  // Well... this is all !
}

By this time you are already wondering what is the reason for this post and what is the link between Groovy properties and mocking (beside maybe advertising the coolness of Groovy mocks). Well, if you would be using Groovy mocks for a while you would have noticed that you cannot actually mock the property access (there was an workaround: explicit use of the getter, but this would have defended the whole idea around properties, didn’t it?). So, fresh on the Groovy trunk there is support for mocking property access:

class Caller {
  def printTwo = { new Collaborator().one }
}
def mock = new MockFor(Collaborator)

mock.demand.getOne { "two" }
mock.use {
   def c = new Caller()
   assert    c.printTwo() == "two"
}

Considering that I got started on mocks, my next post will be about JMock2 and the (many) things I don’t like about it.

Update: it looks like there is still one limitation for Groovy mocks/stubs: they cannot be used yet for constructors (GROOVY-1823). Code like this will not run:

def dateStub = new StubFor( Date )
dateStub.demand.Date{ aControlCurrentTime } // this syntax is however ugly

Advertisement

TestNG gets a full book chapter

I was happy to discover that TestNG is now covered in a full chapter of the book Beginning POJOs by Brian Sam-Bodden.

The author puts aside JUnit, and introduces the reader to TestNG concepts. After a concise intro, the author builds more complex tests integrating DbUnit and EasyMock (as you may already know EasyMock 2 is already JUnit-free; in previous posts I have started posting ideas about a JUnit-free JMock).

Regarding the examples provided in the book, I have a single remark: having in mind that building a Hibernate SessionFactory is considered an expensive operation, I would use other mechanisms from TestNG that may help running the tests more quickly (by guaranteeing that the SessionFactory is created/initialized only once): @BeforeGroup (guaranteed to run once before a named group of tests), @BeforeTest (which is guaranteed to run once before the tests) or @BeforeSuite (running once before the whole suite).

category: Software Testing, Testing, TestNG, EasyMock

More on JMock and TestNG

Firstly, I would like to provide a small fix to the code provided in the previous entry: JMock for TestNG (or JUnit-free JMock)

/**
* Verify the expected behavior for the mocks registered by the current thread and
* also releases them.
*/
public static synchronized void verifyAndRelease() {
   Thread currentThread= Thread.currentThread();
   List mocks = s_mockObjects.get(currentThread);
   if(null != mocks) {
       try {
           for(Verifiable verifiable : mocks) {
               verifiable.verify();
           }
       finally {
           // make sure the mocks are released
           mocks.clear();
           s_mockObjects.put(currentThread, null);
       }
   }
}

The fix assures that even if the verification of a mock fails, the current mocks are released and will not remain around till the next test.

I have started to completely free JMock of its JUnit “addiction”. I have found three types of dependencies:

• classes in the hierarchy of org.junit.TestCase (3). These can be completely replaced by the class I have already posted
• usage of org.junit.AssertionFailureException. Having in mind that TestNG works for JVM 1.4+, we have directly used the java.lang.AssertError, and I am thinking to do the same here
• a couple of classes extending org.junit.Assert (even if they aren’t using much of it). Considering that TestNG propose a more readable form for assertions through org.testng.Assert, this change is quite trivial

I can confess that these changes are already available on my machine and I am already using them. Me and Joe have been discussing about the possibility to integrate these changes directly in JMock. If this will not happen, than I will most probably include the code in TestNG.

A last point (one that I just get me burnt tonite), is that JMock doesn’t check (or I haven’t figured how to make it) the order of expectations, so from its perspective the following code is same correct (or wrong):

   [...]
   mock.expect(once()).method("methodOne");
   mock.expect(once()).methog("methodTwo");
   [...]
   mock.verify();

and

   [...]
   mock.expect(once()).method("methodTwo");
   mock.expect(once()).methog("methodOne");
   [...]
   mock.verify();

will both pass or fail disregarding the real order of invocation. I agree that in most of the cases, JMock behavior is enough good, but not having a way to force the order of invocation is in my opinion a missing feature. I am gonna try to add this feature to my code.

category: Software Testing, Testing, TestNG, JMock, EasyMock, JUnit