3     Automated Tests

Testing Java EE applications automatically has always been challenging because of the need for some kind of container to run it in. Here we take a look at two approaches that could make life easier: In the first section we use the Groovy and the Spock Framework to write (external) tests for the RESTful Webservices and in the second section we use Arquillian and JUnit to write tests that will be run inside WildFly so we can even test the methods of classes not reachable from the outside. Gradle has a default target to run all tests in the src/test directory:

gradle test

The test results can be found as usual in jtrack-ee7/build/test-results.

3.1   Groovy tests with Spock

Spock is a Test Framework written in Groovy, but compatible with JUnit. Since it is written in Groovy we can benefit from the potential for compact code. Here is how a test case for a RESTful Webservice looks like
(taken from file jtrack-ee7/src/test/groovy/itf/jtrack/RestfulSpec.groovy):

class RestfulSpec extends Specification {

    def "read userlist restful"() {

         println "starting test"

         setup:

              def jtrack = new RESTClient( 'http://localhost:8080/jtrack-ee7/items/')

         when:

              def response=jtrack.get(path: 'user')

         then:

              assert response.status == 200

              assert response.contentType == JSON.toString()

              assert ( response.data instanceof List )

              println response.data

         println "finished test"

    }

Each Groovy Specification consists of three sections

  • setup: prepare the context for the tests
  • when: specify the preconditions
  • then: check the results

We use the Groovy Module HTTP-Builder that gives us the ready to use RESTClient class and makes the processing of RESTful requests and responses very compact and expressive. Spock comes with more features to support the compact writing of tests, for example to specify test input values in a tabular form. Please take a look at http://docs.spockframework.org/en/latest/data_driven_testing.html#data-tables

3.2   Arquillian and JUnit

Arquillian is a JBoss project that enables unit testing inside a Java EE container like JBoss or WildFly. Arquillian can operate in two modes: embedded and remote. In embedded mode, the container is controlled (started and stopped) by Arquillian whereas in remote mode, Arquillian assumes an already running container to which it connects. In our setup, we use the remote mode to make sure the container is started with the system.properties as a commandline parameter.

The first example tests a simple method of a Session Bean. The example can be found in the file
jtrack-ee7/src/test/java/itf/jtrack/ArqTest.java

@RunWith(Arquillian.class)

public class ArqTest {

    @Inject

    ProductManager prodman;

    @Deployment

    public static JavaArchive createDeployment() {

         return ShrinkWrap.create(JavaArchive.class)

             .addClass(Product.class)

              .addClass(ProductManager.class)

              .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")

              .addAsManifestResource("persistence.xml");

    }

    @Test

    public void firstTest() {

         System.out.println("starting tests");

         List<Product> prodlist=prodman.findAll();

         Assert.assertTrue(prodlist.size()>0);

         System.out.println("finish tests");

    }   

}

To make sure the test is run with the correct testrunner, we annotate the whole class with @RunWith(Arquillian.class). Then we can use injection to get us an instance of the ProductManager Session Bean which is our test target. In the method createDeployment() we must list all necessary classes and their direct dependencies to pack them into an archive which Arquillian deploys for the test. We add an empty beans.xml to enable CDI and a generic persistence.xml for database access. Now we can specify our test just like a standard JUnit test.

But Session Beans can be reached and tested from outside the container as Webservices as we did in the previous example. So how about JSF Backing Beans? Fortunately, that works the same way, please have a look at the File ArqManagedBeanTest.java where the WebConversation bean is tested.

4     IDE Support

All the new tools are not much fun as long as they are not adequately supported by an IDE. For this setup I used the Spring Tool Suite (STS) http://spring.io/tools which is based on Eclipse. It is free like Eclipse itself and backed by Pivotal Software, the company behind the Spring Framework and currently also the main sponsor of Groovy and Grails (the java counterpart of the famous dynamic webframework Ruby on Rails). And since Gradle is based on Groovy, STS has very good and mature Gradle Support. In fact, Groovy, Grails and Spring are moving more and more towards Gradle as build tool. Groovy scripts can be started just like Java applications from the toolbar as shell scripts or in the Groovy Console. If you install the complete Spring Features you get of course excellent tooling in the form of wizards, completion and checks for productive Spring development.

After downloading and installing, you need to further install the Gradle and Groovy features from the Spring Update Site. Here is how my setup looks like:

groovy gradle tutorial wildfly

Then you have a Groovy Editor with Code completion and a Gradle View with a task list like the following screenshot, which is quite similar to the list of Ant targets: just double click on one of the tasks and it gets executed.

groovy gradle tutorial wildfly

Together with the well-engineered Git support of Eclipse, STS is really fun to work with. The .project files for STS 3.6 are included so the only thing left is to setup the Classpath Variable JBOSS_HOME that points to the WildFly installation and you should be up and running.

5     Conclusion

We have come a long way: I still remember EJB 1.0 and the respective Application Server Reference Implementation by Sun which forced an unbelievable cumbersome GUI on us for each and every deployment. No scripting, no drop-in deployments. And XML everywhere.

Today with the right tools, Java EE development finally is more fun than pain. Here is my list of best features tools for state of the art Java EE development:

  • Git and WildFly together make it possible to manage all WildFly installations of the complete continuous integration pipeline from workstation to production server
  • Gradle leaves the limitations of XML behind and brings the power of Java and Groovy to the build process
  • The concept of the automatic unique build id can clearly identify every .war/.ear file or application and connects it with a git commit to the source code
  • Spock and Arquillian simplify test development and help to raise software quality
  • With STS there is an IDE that supports all the above tools

Auhor: Martin Welss works as a freelance Java expert and architect in Germany who specializes in state of the art Java Enterprise development, build and test automation and continuous delivery. Check his site at: www.it-focus.de

0
0
0
s2smodern