Help

I'm happy to announce the first alpha release of Arquillian, a framework for running tests in the container. If you want to read more about Arquillian's mission, and how it fits into our vision for testing at JBoss, read Pete's blog.

It is one thing to unit test your code outside of the container, but what happens when you run it inside? Does it still behave the same? How about testing against container managed resources? This is where Arquillian comes into it's own.

With Arquillian it's just as easy to write integration tests as unit tests. In fact, to minimize the burden on you, Arquillian integrates with familiar testing frameworks, allowing reuse of tools such as the JUnit/TestNG support in your favorite IDE, Maven Surefire, Ant - in fact any tool which supports TestNG or JUnit!

To show you just how simple, here is a example test case using JUnit: 

@RunWith(org.jboss.arquillian.junit.Arquillian.class)
public class TemperatureConverterTestCase {

   @Deployment
   public static JavaArchive createTestArchive() {
      return Archives.create("test.jar", JavaArchive.class)
         .addClasses(TemperatureConverter.class, TemperatureConverterBean.class);
   }

}

By using JUnit's @RunWith annotation you tell JUnit to use Arquillian as the test controller. Arquillian will then look for a static method marked with the @Deployment annotation, which creates your micro deployment. In the example above we simply deploy a session bean.

Arquillian hooks into your testing frameworks life cycle and reacts to events. On the before suite and after suite events the container is started/stopped, while on the before class and after class events your micro deployment is deployed to the container and then undeployed.

The test case is started in the local JVM, and then Arquillian overrides the normal test execution and moves it over so that it is executed in the container. By the time the test framework calls your @Test annotated method, the test is running inside the container, giving us the possibility to work with container managed resources. 

@RunWith(org.jboss.arquillian.junit.Arquillian.class)
public class TemperatureConverterTestCase {

   @Deployment
   public static JavaArchive createTestArchive() {
      return Archives.create("test.jar", JavaArchive.class)
         .addClasses(TemperatureConverter.class, TemperatureConverterBean.class);
   }

   @EJB
   private TemperatureConverter converter;

   @Test
   public void shouldConvertToCelsius() {
      Assert.assertEquals(converter.convertToCelsius(32d), 0d);
      Assert.assertEquals(converter.convertToCelsius(212d), 100d);
   }

   @Test
   public void shouldConvertToFarenheit() {
      Assert.assertEquals(converter.convertToFarenheit(0d), 32d);
      Assert.assertEquals(converter.convertToFarenheit(100d), 212d);
   }
}

Note how we can use @EJB to inject the session bean from our deployment into the test case for use in our test method - neat!

The Arquillian TestEnricher SPI supports all the injection annotations from Java EE 6 - @EJB, @Resource and @Inject.

This example test case could run in GlassFish, JBoss AS or OpenEJB as there are no container specific code/configuration at all. The choice is yours. You could even test on multiple platforms!

I want to learn more, where should I go from here?

You can follow up with some in depth usage scenarios and tests described in these articles:

We also have reference documentation which walks you through the examples from Arquillian, and shows you how to create your own Arquillian test suite. You might also find the javadoc useful. You can also check out the forums and more articles can be found on our community site. If your interested in chatting to us, please drop by #jbosstesting on irc.freenode.net

So, what's next?

Some of the things you can expect from Arquillian are:

  • Local run mode -- Sometimes, you don't want to run the test case inside the container itself. A local run mode will be added; a mode where your test controls the deployment but is not deployed as a part of it. This will give you the chance to run a test against, for example, JSF pages or RMI (testing for those nasty Non-Serializable / SessionClosed exceptions).
  • Multiple deployments controlled by same test -- Sometimes your micro deployment is not enough to test on it's own and you want to package other components as part of the same deployment. For example, you need to test the interaction between two Web applications.
  • Support for method argument injection -- In the first alpha we only support field injection. In alpha 2 we will be extending the TestEnricher SPI to include support for method argument injection:
@Test
public void shouldWithdrawFromAccount(@EJB AccountManager manager) throws Exception
{
   ...
}
  • Test method interceptors -- Another planned enricher SPI is a test method interceptor. With this we can add support for transactions:
@Test
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void shouldWithdrawFromAccount(@EJB AccountManager manager) throws Exception
{
   ...
}
  • Convention over configuration -- The micro deployments should be as easy as possible to create, so adding support for common conventions should help speed up the test development. For example we can automatically add all classes in the same package as the test class to the deployment
  • Arquillian controlled resources -- Sometimes the container requires container specific configuration e.g, java.naming.\* parameters needed to create a InitialContext. If the test case has to explicitly deal with this, it places the burden for container portability back on the test case author. Arquillian will provide an extension point to add Arquillian created/managed resources:
// auto creation of InitialContext based on running container, remote or local.
@ArquillinResource
private InitialContext context;

// auto creation of URL to a specific deployed Servlet, including http port/ip etc.
@ArquillinResource(MyServlet.class)
private URL myServletURL;

// the bundle context of a deployed osgi bundle
@ArquillinResource
private BundleContext context;
  • Add support for more containers -- We will plan to support more containers! Currently we have planned: GlassFish 3 (as a remote container), Jetty, Tomcat, Resin, Felix OSGI.
  • Third party integrations -- In the spirit of ease of development, we integrate with existing test frameworks as much as possible, but we are always keen to learn of new frameworks we can integrate with. We already plan to support Selenium for example.

Where can I see Arquillian in use?

Arquillian is a new framework, but it will be used to test all the Seam 3 modules, and will be our recommended solution for testing your Seam application. We'll also replace the current core of the JSR-299 CDI TCK with Arquillian, likely for the 1.1 version of the TCK

If you have any thoughts on these ideas, or would like to suggest some new avenues we should explore, please contact us on the Arquillian Dev forum.

And, what is open source with out the community!

A big thanks to the Arquillian and ShrinkWrap community for helping out on this release by being early adopters, joining in on community meetings, general discussions and writing blogs, articles and patches. In alphabetical order: Dan Allen, Steven Boscarine, German Escobar, Jordan Ganoff, Kent Gullaksen, Pete Muir, Jason Porter, Andrew Lee Rubinger

[JIRA] | [SPI Javadoc API Javadoc] | [Reference Guide] | [Release Notes]

Post Comment