Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Acceptance and Integration Testing in Java EE Using Arquillian

DZone's Guide to

Acceptance and Integration Testing in Java EE Using Arquillian

Arquillian brings in a newer thought process of testing that includes CI and testing within the JEE container, especially for solutions that require functionalities to be tested across various containers.

· DevOps Zone
Free Resource

“Automated Testing: The Glue That Holds DevOps Together” to learn about the key role automated testing plays in a DevOps workflow, brought to you in partnership with Sauce Labs.

In agile projects using Java/JEE, the focus and scope of developer testing are usually diminished to either unit testing or very basic functional testing. Arquillian brings in a newer thought process of integration and acceptance testing that includes Continuous Integration and testing within the JEE container, especially for JEE products or solutions that require functionalities to be tested across various containers. This provides the most productive way. According to the internet, Arquillian was also the "Duke's Choice Award for Developer Productivity at JavaOne Conference 2011." In my experience, it not only enhances the productivity of developers but also promotes good practices. 

It allows you to convert your TestNG or JUnit (among others) test cases into Arquillian test cases with few changes. Also, it allows you to directly use CDI in your test code. This allows you to inject dependencies such as EJB or web services directly in your test cases. The central thought process involved in using Arquillian is the ShrinkWrap API provided by it. It allows you to package your product or project code into Archives like JAR, WAR, and EAR. Along with the project code that is to be tested, the test cases are also packaged. It then allows multiple Maven configurations to allow direct deployment into one of these modes (that we used for our product).

1. Outside Container

By allowing a Weld-EE container Arquillian Maven Profile, we are in effect allowing an outside container testing environment. This should be helpful in large, unwieldy projects or products to get a saturation or complexity point in logic or functionality development. There are a few limitations of this profile that the developer may not be able to inject container resources like managed thread factories, data sources or cache containers. The developer can go building all the logic and functionality and do both the unit testing and integration testing with other components of the product; until that time, there is a need to inject resources that are not provided by this profile. The guideline for usage of this profile should ideally be the very initial development phase of a Sprint story.

2. Remote Container (Managed Container)

By allowing either of these Arquillian Maven profiles, we are in effect allowing an inside container testing environment. Once we are over the initial phase of a sprint story, the Continuous Integration cycle should now involve integration testing with other product components on a daily basis. This also includes changing requirements and possibly regression during the Sprint cycle. Also, there is a need to start testing with all container resources available. This should be the possible point, that you either start using the remote or the managed container. The ShrinkWrap allows you to directly connect to local or remote host servers to deploy the created or testable archive. This is done by providing an Arquillian configuration file.

It supports a variety of JEE container profiles such as Wildfly, JBoss, Glassfish, Websphere, Weblogic, and Tomcat (among others). By allowing Continuous Integration testing with other components, we catch integration defects very early in the cycle. In a way, it matches the punchline of Arquillian (You can rule your code, not the bugs." or "Death to all bugs!"). Also, providing a way of developer regression testing suites, it allows developers to go ahead safely with the changes in the product. It also automatically promotes good practices by not allowing any thought processes to be lost during the development and allowing developers to write more test cases that start testing regression effectively and allow more functionality coverage. The guideline for usage of this profile should ideally be the middle-to-end development of a Sprint story.

3. Embedded Container

Now, we are through with the initial and even the middle-to-end cycle of our development. However, all throughout this, there could be a central or nightly build running at the product level. The embedded container would be the most suitable in my experience, to automatically start off the container, deploy the ShrinkWrap and do all the integration test (regression as well). By doing this on a daily basis in scheduled product builds or nightly builds, the confidence level on the product code increases by a very high magnitude. When testing across containers, it should reduce developer and tester effort by appreciable levels. Also, the manual task of actually deploying and testing across containers is not required. The guideline for usage of this profile should ideally be the nightly builds for a sprint.

For all of the above profiles, TestNG or JUnit test reports are created, which allows you to understand the outcomes better. Also, in most products, the development cycle that is followed by individual developers on their systems is equivalent to:

Code > Build > Deploy > Test > Fix > Deploy > ... [Code]

With Arquillian, in effect the daily cycle is shortened to:

Code > Fix > ... [Code]

The above caters to integration testing and regression testing. Once we decide on Arquillian in our products or solutions, making it an inherent part of the agile planning processes, we should enter into a TDD approach for acceptance testing as well. The pre-planning and planning process (which includes story identification, estimation, and work distribution) could trigger off the initial activity of identifying acceptance tests. These acceptance tests should be accepted or signed off by the architect, reviewer, or owner. So, in effect, though there can be modifications, additions, or subtractions, the acceptance test should start becoming the final sign-off for the successful delivery of the Sprint story.

With Arquillian, this ATDD approach can be easily implemented or automated. The actual implementation of these acceptance tests will happen during the Sprint cycle. The Sprint deliverable that is now available to the testing team for a product for the next Sprint is bound to have one very initial but even more thorough level of functionality testing completed by the developers. With acceptance (and integration) testing reports made available through Arquillian, the testers' time is now saved and they will be able to concentrate on identifying diverse, granular or simply more thought-out test cases and increase overall product quality.

The salient features of Arquillian, then, are:

  • Real tests inside the JEE container.

  • IDE/Eclipse friendly integration test cases.

  • Test enrichment and allowing CDI directly in test.

  • Classpath control and isolation; no environment Bugs!

  • Debug directly on the server or JEE container.

  • Container agnostic and various JEE containers are supported.

  • Extensible platform and support frameworks like JUnit/TestNG.

  • Integration tests from Maven builds inside container.

Learn about the importance of automated testing as part of a healthy DevOps practice, brought to you in partnership with Sauce Labs.

Topics:
jee ,acceptance testing ,integration testing ,devops

Published at DZone with permission of Sumith Puri, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}