Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2573 posts at DZone. You can read more from them at their website. View Full User Profile

Java EE Testing 'Gets Real'

05.23.2010
| 16692 views |
  • submit to reddit
Arquillian (pronounced ar-kill-e-an) is changing the way that testing is done in Java EE.  Dan Allen, a Senior Software Engineer at JBoss, found that a lot of the complaints about Java EE claim that it's not testable.  Although there have been a lot of improvements over the years, you still need to test things as they really run.  He explains, "You can't say 'well, it works with a unit test, let's throw it over the fence and see if it runs.'" 

In a recent presentation, Allen shared some interesting statistics about why some Java developers don't test.  Time pressure is the biggest reason why developers don't test, according to his survey.  But there are other reasons too...

The results also showed that slow builds and difficulty building integrated and functional tests were some of the main reasons for time consuming testing.  However, Allen says there's still hope for those who use Java EE.  JBoss is currently developing two open source projects, Arquillian and ShrinkWrap, that will make JEE testing a lot easier and more 'real'.

Arquillian abstracts away container lifecycle and development from test logic so that developers can easily develop a broad range of integration tests for Java EE applications.  For all intents and purposes, the Arquillian class is a managed bean inside the container.  It's intention is to solve a lot of the common integration testing challenges:

  • Active mocks to stand in for collaborators
  • Configure application to use test data source(s)
  • Deal with (lack of) classpath isolation
  • Run a build to create/deploy application archive

Arquillian essentially lets you skip the build and test 'in-container' (any place where a runtime is managed and a component model, set of services, and resources are provided).  It essentially lets you build in Java, so that's why the tagline is "skip the build".  Here are a lists of Dan Allen's in-container pros and cons:

Pros
  • Relies on shared memory
  • Pass-by-reference
  • Don't need remote views
  • Managed concurrency

Cons
  • Lack of isolation
  • Environment not "true" if embedded

The environment, however, is true if the test runs in the actual target server.  Arquillian also has a feature to keep it isolated while in the container.  More benefits of Arquillian include:

  1. Have as much or as little "integration" as you need
  2. Looks like a unit test and you get fully functioning components
  3. Less code to write
  4. Has a simple method for getting an instance of a component under test
  5. You don't hesitate when you need a resource
  6. Same test, multiple containers

Arquillian runs in both embedded and remote Java EE containers.  In an embedded container, the same JVM as the test runner is used, the tests are executed by a native test runner, and the lifecycle is controlled by Arquillian.  In a remote container, a separate JVM from the test runner is used, tests are executed over remote protocol, and Arquillian will likely bind to the ports.  Here is a list of containers that Arquillian can currently run in:

  • Java EE application servers (JBoss AS, GlassFish, etc.)
  • Servlet containers (Tomcat, Jetty)
  • OSGi
  • Managed bean containers (Weld SE, Spring, or a bootstrapped CDI environment)

Your options don't end there because the SPI allows you to introduce any other container simply by adding the Deployable Container interface in Arquillian to the classpath of your desired container.

ShrinkWrap is another integral part of the Arquillian testing architecture.  It is a Java API that assembles archives (JARs, WARs, and EARs) and defines which classes we want defined in a particular test.  The ShrinkWrap component lets you build in Java and "skip the build."  In order to build for the integration test, Arquillian solves a lot of problems by using ShrinkWrap.  Here are its main benefits:

  1. IDE incremental compilation: save and re-run, skip the build!
  2. Simple API
  3. Tooling Views within your context
  4. Export and debugging
  5. Micro-deployments

Micro-deployments deploy the components in isolation and allow developers to test one slice at a time.  You don't need to wait for the full application to build and startup.  You can also fine-tune the size of integration.

Dan Allen's presentation on Arquillian and ShrinkWrap, "Real Java EE Testing with Arquillian and ShrinkWrap," dives deep into Arquillian and ShrinkWrap with overviews and examples.  Check out the SlideShare presentation, with audio.  Also, see Arquillian in Action and the upcoming new features.

Comments

Dan Allen replied on Mon, 2010/05/24 - 1:44pm

Aslak and I will be presenting on Arquillian at Jazoon next week. We plan to show rather than tell, giving you 20 minutes of non-stop demos.

Andrew Rubinger replied on Mon, 2010/05/24 - 1:59pm

My upcoming book on EJB 3.1 will feature examples fueled by Arquillian and ShrinkWrap.  Looking forward to discussing these at JBossWorld in June and JavaOne with Dan in September.

Now is also a perfect time to get involved with contribution.  We're picking up steam and are dedicated to growing to meet real user demand.

S,
ALR

 

Manuel Jordan replied on Mon, 2010/05/24 - 4:06pm in response to: Andrew Rubinger

Very Interesting your future book, I will waiting eagerly your book =)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.