Developing Behavior-Driven Tests for JEE Web Applications with Jbehave – Part III

Automating the tests and generating reports

Previously, we implemented the step cases in a Java code.  In this, Part III of our series, we’ll learn how to automate them and generate informative reports at the end of the run.

Identifying implementation methods

As you may recall, we mentioned that Jbehave registered the Java implementation methods on start up. But how does it identify an implementation step?

Basically, these methods would have to override the configuration() method, which is part of the jbehave library. We have however, let ‘thucydides’ work for us. The ‘thucydides-core’ library (that comes with the ‘jbehave-plugin’), provides the ‘ThucydidesJUnitStories’ class. This identifies the ‘.story’ files and the links for the Java implementations. All we need is to have a Java class that inherits from it in the Java implementation root package:

Final project structure

Running the tests

At this point, we can run the tests as Junit.

Running the tests manually

For the black-box tests to pass, we need to have a server up and running.

To run the tests with the IDE, right-click the jbehave package.

In this manner, we can run the tests quickly, debugging them and the server.

Automating the tests with Jetty(Maven plugin)

What we really want is to test the Volcano server as part of the Maven build, the ‘maven compile’ task. In this case, we require Maven to start a Volcano HTTP server, run the tests, and get Volcano down.

Eclipse Jetty is an open-source project providing an HTTP server and javax.servlet container. We’ll use a Jetty Maven plugin, to start a Volcano server on which the tests will be running.

The Maven plugin should be configured as follows:

Note the following:

1. The server’s port must be available, you may want to declare a different port from the default that your server is using.
2. The memory you declare allocated with the jvmargs must be enough to get the server up
3. In ‘contextHandlers’ we provide the web application archive to be used. If you have multiple web modules in your project that need to be tested, provide them all.
4. In the executions section we tell jetty to start before the tests are executed and stop afterwards. If we don’t explicitly ask that, then the jetty would stay up.

Test Summary Reports

Test Summary Reports are an important deliverable. They are needed to reflect test results in a clear way, allowing them to be analyzed quickly.

Jbehave storyReporter supports many report formats and will generate the reports for each step and story automatically after the tests have been completed in the /target/jbehave folder.

We’ll use another Thucydides Maven plugin to generate some better-looking reports:

This generates various reports automatically at the end of the Maven run, in /target/site.

The ‘index.html’ file that has been created is the most comprehensive, interactive report:

A click on the ‘change password’ test (story) for example, would provide some additional data on each step result.

You can zoom in with a click on the various test components to get results and statistics.

Wrapping up

Behavior-Driven Development is a methodology for developing software through example-based communication among Developers, QAs, and Project Managers.

With Jbehave, this means writing Given-When-Then scenarios to illustrate examples in a plain text, which links to Java implementation methods.

As part of our mission to create Blackbox tests in a BDD fashion for the Volcano application, we’ve covered some test cases, discussed design and challenges and reviewed some post-compilation reports.

‍