Arquillian Tamed

Ok, I think I have the basics of Arquillian covered. I’ll start a page some time later with a kind of cookbook, but this post will just be about the results.

What I like about Arquillian

Let’s be simple about this: if you have a pure JEE project, I think Arquillian rocks! It will allow you to run JUnit tests in the context of a JEE container, integrated into a Maven build. No need to look for anything else, you’ll be able to test your code with a lot of containers; GlassFish, JBoss, Jetty, Tomcat, WebSphere and WebLogic. Additionally, you can run with Apache OpenEJB, Apache OpenWebBeans, and Weld. Granted, not all versions are supported, but the list is impressive. Oh yes, it even does remote containers from within Eclipse!

What I think Arquillian can do better

In a word: Shrinkwrap. Shrinkwrap is definitely the Achilles heel of Arquillian. Arquillian assumes your code can be packaged easily for testing and you have to hand-craft the deployment’s content list. If the deployment needed to support a particular Unit test requires a lot of external jars, you’re in for a puzzle. Granted, there is a resolver package which allows you to use your pom, but the documentation immediately sends you off to an Alpha-build add-on, because the current version is too limited. And if you decide it’s too much bother and just tell the resolver to gather all runtime and test dependencies, you’ve just condemned yourself to a lengthy process of gathering dependencies and building a war. Ok, ok, it’s not that much of a bother if your run on a build server, but for “let’s see what this button does” testing, I think it is taking too long. Blame me for being impatient.

The other thing I don’t like is the granularity of test deployments: One per Unit test class. Test Suites aren’t supported, so if you have a dozen test classes, you’ll go through a dozen package-deploy-test-undeploy cycles, even if the deployment is the same. Now that is a waste of cycles if I ever saw one.

My Rules for Survival

  1. Try to keep your dependencies in hand. Don’t put a broad spectrum list in your pom to “save time”, because Arquillian will gobble up the savings.
  2. Apply the KISS principle to the deployment. Try to find a minimal set of classes to support your test.
  3. If you don’t expect container specific limitations, or accept the possibility of container specific bugs, go for an embedded container such as GlassFish 3.1, or even Weld if that suffices. The tests can run as a part of the maven build process which save time.
  4. If you don’t really have external jar dependencies, or only private ones, go for a jar deployment. Otherwise, test in a war, so you can add libraries as a library.

Summary

I’m going to use Arquillian for all my JEE app Unit testing, but I sure hope they’ll add Test Suite support and get that Maven pom resolver out of Alpha.

Advertisements
This entry was posted in Tools and tagged , , , . Bookmark the permalink.

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