Java EE Testing 'Gets Real'
Java EE Testing 'Gets Real'
Join the DZone community and get the full member experience.Join For Free
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:
- Relies on shared memory
- Don't need remote views
- Managed concurrency
- 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:
- Have as much or as little "integration" as you need
- Looks like a unit test and you get fully functioning components
- Less code to write
- Has a simple method for getting an instance of a component under test
- You don't hesitate when you need a resource
- 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)
- 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:
- IDE incremental compilation: save and re-run, skip the build!
- Simple API
- Tooling Views within your context
- Export and debugging
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.
Opinions expressed by DZone contributors are their own.