Cake Solutions Team Blog

Mockery is a new JMock class. It allows you to create mock implementations of your interfaces in your unit tests.

In the days before Mockery, you could still use JMock’s Mock class and then use human-readable style of configuring the expectations. For example, to mock the Sender interface and its send(String s) method, you’d write

Mock sender = new Mock(Sender.class);
PostOffice postOffice = new PostOffice();
postOffice.setSender((Sender)sender.proxy());

sender.expects(once()).method("send").with(eq("Hello")).isVoid();
postOffice.post("Hello");

Now, assuming the PostOffice.post(String s) uses the Sender implementation to ultimately send the message, this test would work. However, if you refactored the Sender.send(String s) method, your IDE would not be able to refactor the JMock expectation.

Enter Mockery

The same code using JMock’s new Mockery class would look like this:

Mockery context = new Mockery();
final PostOffice postOffice = new PostOffice();
final Sender sender = context.mock(Sender.class);
postOffice.setSender(sender);

final String message = "Hello";
context.checking(new Expectations() { {
    one(sender).send(message);
} });
postOffice.post(message);

Here you can see that the test still reads very well, but most IDEs will automatically refactor the unit test expectations whenever you refactor the Sender interface. Also notice that you do not need to explicitly state with(eq("Hello")) or with(eq(message)). Instead, you “call” the mocked method directly, passing it the values to be checked.

There is a lot more to Mockery, we recommend that you give it a fair try in your unit tests.

I am sure you remember your mother telling you to clean your room when you were little. This usually involved taking out the hoover (or the vacuum cleaner for the Yahoos) and getting on with the job.

Fast forward a few years and switch to PostgreSQL. It is very good idea to turn on the auto_vacuum parameter or vacuum the tables manually every few days. If you do not do that, you may end up with a database with just a few tens of thousands of rows occupying over 4.5 GB on the hard drive.

We are going to start using the theory of constraints to control our projects; I believe we have more resources than we need. I am hoping to prove that we can either all finish at four o’clock every day or take on more work and earn more money.

If you are interested, check out Wikipedia. I will send charts that display the buffer consumption and the feeder buffer consumption in a few weeks’ time. You will see just how easy it is to control all your projects.

We are playing around with the JBoss application server 4.2.2GA and Spring JMS. The whole setup is very simple; assuming you want to use a JMS queue, you need to configure it in JBoss and then use the new Spring 2.5 jms namespace.

Let’s begin with the JBoss configuration. You need to drop the *-service.xml file into $SERVER_DIR/deploy/jms. The contents of the file define the destinations and queue names; the file we will show here includes two queues.

<server>
  <mbean code="org.jboss.mq.server.jmx.Queue"
	 name="jboss.mq.destination:service=Queue,name=invoice-data">
    <depends optional-attribute-name="DestinationManager">
        jboss.mq:service=DestinationManager
    </depends>
    <depends optional-attribute-name="SecurityManager">
        jboss.mq:service=SecurityManager
    </depends>
    <attribute name="MessageCounterHistoryDayLimit">-1</attribute>
    <attribute name="SecurityConf">
      <security>
        <role name="guest" read="true" write="true"/>
        <role name="publisher" read="true" write="true" create="false"/>
        <role name="noacc" read="false" write="false" create="false"/>
      </security>
    </attribute>
  </mbean>

Next, we define the Spring queueConnectionFactory and jmsTemplate beans, as shown in the following context file

<beans>
...
    <jee:jndi-lookup jndi-name="java:ConnectionFactory"
        id="queueConnectionFactory" expected-type="javax.jms.ConnectionFactory"/>
    <bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate102">
        <property name="connectionFactory" ref="queueConnectionFactory"/>
    </bean>
    <jms:listener-container
        connection-factory="queueConnectionFactory"
        concurrency="10">
        <jms:listener destination="invoice-data"
             ref="mdb" method="mdbMethod"/>
    </jms:listener-container>
...
</beans>

The mdb bean refers to a standard POJO with the mdbMethod. The signature of the mdbMethod follows pattern void mdbMehtod(argument). Now, depending on the type of the message, the argument is either the object we send in ObjectMessage or String if we send TextMessages.

In our Spring 2.5 flagship project, we have chosen to use JUnit 4 and its constraint-based asserts. This is similar to how you write mock objects using the jMock library.

In short, the assertions take form of assertThat(T t, Constraint<T>). The Constraint<T> is an interface that the framework calls to validate the value t.

To get started, download JUnit (4.4) and jMock, unzip the downloaded file and jump straight into writing a test.

import static org.junit.Assert.assertThat;
import org.junit.Test;

public class InvoiceTest {

    @Test public void testAddLine() {
        Invoice invoice = new Invoice();
        InvoiceLine line = new InvoiceLine();
        invoice.addLine(line);
        assertThat(line, org.hamcrest.collection.IsIn.isIn(invoice.getLines()));
    }

}

So here you have it. Your first test using JUnit jMock-style constraints rather than TestCase.assertXXX calls.