About Paris Apostolopoulos

Paris is a senior software engineer focusing on J2EE development, loves Business process modelling and is keen on software quality challenges. He is passionate about Java and Java communities. He is a co-founder and administrator of the first Java User Group in greece(JHUG.gr) and occasional speaker on meet-ups and seminars and regular blogger.

Java EE7 and Maven project for newbies – part 5 – Unit testing using Arquillian / Wildfly 8

Resuming from the previous parts

Part #1, Part #2, Part #3, Part #4,
This is the first ‘extra’ post, based on the  maven JavaEE7 demo project I am ‘building’ on this series of blog posts. We have already defined a solid structure and some modules. One very common case in an application like this, is to use Arquillian (+JUnit), a god sent framework, that enable us to unit test our EJB services using a ‘real’ application server, most probably the same that we are going to deploy to. I am actually following the basic setup guide as it can be found here, the difference is that I am going to setup Wildfly 8.1 as my embedded container to host my unit tests.
Widlfy 8.1 is a fully blown JavvaEE7 container, so I can safely test all my features.

Arquillian mind set and Maven

One of the basic things you need to understand in order to adopt Arquillian in your Maven-ized project is the following  terms (ideas) that are actually implemented as dependencies.

  • You need the Arquillian framework/library of course, imagine that it is a new car but is missing it’s engine. The front part it’s empty.
  • You need an Arquillian Container Adapter, imagine that you need to install some kind of placeholders in the front part of your car, something like a frame that is going to be used so that an engine can be ‘installed’.
  • You need a real container (application server), this is the engine that we are going to fit into our car.
  • You need JUnit, this is the ‘test track‘ that your car is going to run and be tested.
  • You need your code (your EJB(s)), these are the passengers that are going to be placed in the car and test a ride on the Junit track.

Defining the dependencies on the parent pom

As we have already elaborated in the previous 4 posts, the parent pom is the place to define the dependencies and their versions of libraries to be used in our application.  Have in mind the above list of terms let’s get started and update the dependencyManagement section  of our parent pom.

	

     <junit-version>4.11</junit-version>
     <arquillian-version>1.1.4.Final</arquillian-version>
     <arquillian-wildfly-version>8.1.0.CR2</arquillian-wildfly-version>
     <arquillian-transaction-version>1.0.1.Final</arquillian-transaction-version>
    </properties>
     <dependencyManagement>
          <dependencies>
              <dependency>
                  <groupId>javax</groupId>
                  <artifactId>javaee-api</artifactId>
                  <version>${javaee-api-version}</version>
              </dependency>
              <!-- -JUNIT-->
              <dependency>
                  <groupId>junit</groupId>
                  <artifactId>junit</artifactId>
                  <version>${junit-version}</version>
              </dependency>
              <!-- rquillian itself-->
              <dependency>
                  <groupId>org.jboss.arquillian</groupId>
                  <artifactId>arquillian-bom</artifactId>
                  <version>${arquillian-version}</version>
                  <scope>import</scope>
                  <type>pom</type>
              </dependency>
              <!-- this is in an extention to arquillian it is optional-->
              <dependency>
                  <groupId>org.jboss.arquillian.extension</groupId>
                  <artifactId>arquillian-transaction-bom</artifactId>
                  <version>${arquillian-transaction-version}</version>
                  <type>pom</type>
                  <scope>import</scope>
               </dependency>
               <!-- this is container adapter for wildfly-->
                <dependency>
                   <groupId>org.wildfly</groupId>
                   <artifactId>wildfly-arquillian-container-embedded</artifactId>
                   <version>${arquillian-wildfly-version}</version>
                </dependency>
                <!-- this is the wildfly emb.container - BUT eventually it is not a fully blown emb.container-->
                <dependency>
                   <groupId>org.wildfly</groupId>
                   <artifactId>wildfly-embedded</artifactId>
                   <version>${arquillian-wildfly-version}</version>
               </dependency>
           </dependencies>
     </dependencyManagement>

Some tips on the above fragment:

  • Some of the dependencies are of type pom, and scope import. This is actually a special case on defining group of dependencies all together. A pom type dependency, means that this is a group of individual libraries grouped together under this definition. You only need to define this uber pom  and you will inherit the individual dependencies within it. In the Maven terminology this grouping of dependencies are called ‘BOM‘ or also known as Bill of Materials. Arquillian is consisted of several concrete libraries and dependencies, instead of defining each one of the, one by one, we have the same result if we define the arquillian-bom.
  • The ‘arquillian-transaction-bom‘ is an optional dependency, you may not define it, it adds extra features to the arquillian engine and in your tests. One of the most famous ‘extra’ features is the ‘@Transactional’ arquillian annotation. See details here or here.
  • A special case, for Wildfly and JBoss. You will notice the dependency, ‘wildfly-embedded‘, you will assume that this is a ‘embedded‘ uber jar version of the Wildfly application server, like the one for Glassfish. Eventually this is not, and this is a common mistake that people make when trying to setup Arquillian with Wildfly. In order to make the whole thing work you need to download the ‘real’ application server. Have a look on the following section, where will will tackle this special case.

Configuring our ejb module for Arquillian and tests

In our demo applications we have ‘coded’ most of our EJB services on the module called sample-ejb. So we need to add extra configuration to it’s pom in order to ‘fire‘  junit+arquillian tests during the test phase of this module.

Most of the configuration will do on this pom, is to cover this ‘special‘ case of Widlfly not being offered as a fully blown embedded container. So in order to make the whole mechanism work we need, to tell Maven, during our test phase, to download the Wildfly.zip (as we would do using a browser for example) unzip it somewhere, and the point Arquillian to the path. Once that is done, rAquillian will take over.

Downloading the wildfly server, before hand

The configuration below is written in the sample-services pom, our ‘EJB services’ module:

     <plugin>
            <artifactId>maven-dependency-plugin</artifactId>
                 <executions>
                  <execution>
                     <id>unpack</id>
                         <phase>process-test-classes</phase>
                          <goals>
                              <goal>unpack</goal>
                           </goals>
                     <configuration>
                     <artifactItems>
                         <artifactItem>
                            <groupId>org.wildfly</groupId>
                            <artifactId>wildfly-dist</artifactId>
                             <version>8.1.0.Final</version>
                             <type>zip</type>
                             <overWrite>false</overWrite>
                             <outputDirectory>target</outputDirectory>
                         </artifactItem>
                     </artifactItems>
                  </configuration>
               </execution>
           </executions>
      </plugin>

Some tips on the above fragment:

  • We use the maven-dependency-plugin
  • We instruct the plugin to kick in during the ‘process-test-classes’ phase of the Maven lifecycle, and when it kicks in to execute the ‘unpack’ goal. So before Maven starts running the tests the above part of the configuration will have downloaded and unpacked Wildfly 8.1 to the class path.

 Running the tests, using maven – surfire plugin

Again the code below is part of the sample-services.pom. We actually configure Maven Surefire Plugin, which is the plugin that executes the Junit-Arquilian tests.

    <plugin>
         <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-surefire-plugin</artifactId>
          <configuration>
            <!-- Fork every test because it will launch a separate AS instance -->
             <forkMode>always</forkMode>
             <systemPropertyVariables>
                <java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
                <jboss.home>${project.basedir}/target/wildfly-8.1.0.Final</jboss.home>
               <module.path>${project.basedir}/target/wildfly-8.1.0.Final/modules</module.path>
              </systemPropertyVariables>
              <redirectTestOutputToFile>false</redirectTestOutputToFile>
         /configuration>
     </plugin>

Some tips on the above fragment:

  • Surefire provides the execution environment for the unit tests. In our case we have Junit-Arquillian powered tests. In order Arquillian to correctly initialize itself and to identify the container we need to pass as system parameters, the path of the download application server. Remember that wildfly / jboss is a special case.  The container will already be downloaded on out /target folder.

Add the required dependencies on the sample-services module

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
        </dependency>
 
        <dependency>
            <groupId>org.jboss.arquillian.junit</groupId>
            <artifactId>arquillian-junit-container</artifactId>
            <scope>test</scope>
        </dependency>
 
        <dependency>
            <groupId>org.wildfly</groupId>
            <artifactId>wildfly-arquillian-container-embedded</artifactId>
            <scope>test</scope>
        </dependency>
 
        <dependency>
            <groupId>org.wildfly</groupId>
            <artifactId>wildfly-embedded</artifactId>
            <scope>test</scope>
        </dependency>
 
        <dependency>
            <groupId>org.jboss.arquillian.extension</groupId>
            <artifactId>arquillian-transaction-jta</artifactId>
            <scope>test</scope>
        </dependency>

 Create a sample Test

      package gr.javapapo;
     
    import org.jboss.arquillian.container.test.api.Deployment;
    import org.jboss.arquillian.junit.Arquillian;
    import org.jboss.shrinkwrap.api.ShrinkWrap;
    import org.jboss.shrinkwrap.api.asset.EmptyAsset;
    import org.jboss.shrinkwrap.api.spec.JavaArchive;
    import org.junit.Assert;
    import org.junit.Test;
    import org.junit.runner.RunWith;
     
    import javax.ejb.EJB;
     
    /**
     * Created by papo on 5/31/14.
     */
    @RunWith(Arquillian.class)
    public class DemoArquillianTest {
     
        @EJB
        UserServices dummyService;
     
        @Deployment
        public static JavaArchive createDeployment() {
            return ShrinkWrap.create(JavaArchive.class)
                    .addClass(UserServices.class)
                    .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
        }
     
        @Test
        public void testSaysHello() {
            Assert.assertEquals("hello",dummyService.sayHello());
        }
    }

We are done

Under the sample-parent folder level, type:

mvn clean package
Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

2 Responses to "Java EE7 and Maven project for newbies – part 5 – Unit testing using Arquillian / Wildfly 8"

  1. Kapil says:

    Hi,

    Thanks for the tutorial.

    How can I add resources (eg. persistence.xml) from dependent modules in the createDeployment method.

    Regards,
    Kapil

  2. javapapo says:

    Take a look on part6 of this tutorial
    http://javapapo.blogspot.gr/2014/06/java-ee7-and-maven-project-for-newbies_23.html

    Where I add resources. (e.g a test-persistence.xml)

    :)

Leave a Reply


− 1 = three



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books