Skip to content

Mockingbird: Testing Registration Process with Apache James

by on February 11, 2013

Mockingbird was the codename for a project I launched on the recent CoreMedia Hackathon, a meanwhile regular hacking session at CoreMedia where developers can experiment with new technologies or give the CoreMedia WCMS a push beyond the limits. This time many projects focused on the new product CoreMedia 7 – just as Mockingbird from the QA perspective.

With CoreMedia Elastic Social we offer integrated commenting and rating for websites of our customers. And one aspect is the user registration process which requires to fill in a form, receive an email and confirm the registration process via a link provided in the email.

While in the past we used the Wiser framework for testing it was for some reasons not a solution we could use in our multi-team development and test environment (also known as Retest Systems).

What we needed was a way to automatically test the registration process while the System Under Test (SUT) should still be available for manual testing approaches. This is where the project Apache James promised a smooth integration. And it fulfilled the promises!

Here is the story we wanted to test (we skipped the full confirmation roundtrip so far):

Given I opened a website with CoreMedia Elastic Social
When I register with my email address M
Then I will receive a registration mail at M.

We are talking Gherkin as you see although not using Cucumber and alike. But that is another story.

In preparation for our tests we set up Apache James just aside the regular retest system and directed the mail configuration of the system to Apache James. We used Apache James 3.0-beta4 as we wanted to use JMX to access the server during the tests. Starting Apache James was a piece of cake. Just run run.sh and you are (almost; see below) done. Apache James integrated transparently into the system. For manual testing the mail handling just got forwarded to our internal mail servers while for the tests we could generate users on the fly with the mails stored just within Apache James.

Why only almost fine after starting James? Because for remote access to JMX we had to do two adjustments:

  • in wrapper.conf we had to set com.sun.management.jmxremote.ssl to false and
  • copy jmx-template.properties to jmx.properties and set the machines hostname explicitly (localhost did not work for that machine).

While we used Selenium WebDriver for the registration process on the web site, we used James’ JMX for the preparation of test email accounts in Apache James and then used standard JavaMail to receive the confirmation mails.

Here is a rough sketch for creating a user via JMX, skipping the creation of a domain which is required to do before:

String USERSREPOSITORY_OBJECT_NAME =
    "org.apache.james:type=component,name=usersrepository";
String JMX_URL =
    "service:jmx:rmi://localhost/jndi/rmi://localhost:9999/jmxrmi";

MBeanServerConnection getServerConnection() {
  JMXServiceURL jmxUrl = new JMXServiceURL(JMX_URL);
  JMXConnector jmxc = JMXConnectorFactory.connect(jmxUrl, null);
  jmxc.getMBeanServerConnection();
}

void createUser(String name, String domain, String password) {
  String address = String.format("%s@%s", name, domain);
  MBeanServerConnection mbeanServerConn = getServerConnection();
  ObjectName objname = new ObjectName(USERSREPOSITORY_OBJECT_NAME);
  UsersRepositoryManagementMBean userRepository =
      MBeanServerInvocationHandler.newProxyInstance(
          mbeanServerConn, objname, UsersRepositoryManagementMBean.class, true);
  createDomain(mbeanServerConn, domain);
  userRepository.addUser(address, password);
}

In order to ensure that the mail is really delivered to the target account we also had to flush the mail via JMX using the objects named:

  • org.apache.james:type=component,name=queue,queue=outgoing and
  • org.apache.james:type=component,name=queue,queue=spool

both of type MailQueueManagementMBean.

The required artifacts org.apache.james:james-server-data-api and :james-server-queue-api are both available via Maven Central.

The retrieval via JavaMail was the next challenge. But the only real lesson we had to learn was to pre-fetch the received messages and save them for later assertions as the Message object is only filled lazily.

As a last step, and this is what I really like, we also removed the Mail user via JMX again and thus had a clean system after the test ran.

Here are some links which helped us during the development process:

From → Dev, Testing

Leave a Comment

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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