Using Jbehave for microservices integration testing

More and more organizations are adopting microservices architecture into their ecosystems. In this manuscript we are proposing a guideline which describes how to write automated tests for REST API application that includes several microservices. We have created an application written in Java, which uses the JBehave and Thucydides frameworks. Basic knowledge of Java is required; familiarity with RESTTemplate library and Maven is even better. This infrastructure can be used either locally or in staging and production environments and can also be integrated with Jenkins.

Project overview

In order to demonstrate how you can write automated API tests we have generated a project named example_root. (This project includes two microservices: image_capture and image_converter, each of which has three modules. Image_capture “captures” an image from the web and sends a request to image_converter to convert the captured image. Image_capture includes three modules, image_capture_client, image_capture_service, image_capture_tests.)

image_capture_client includes models of the image_capture app. There is an advantage to testing the project inside of the tested microservice: The developer is able to use classes of the tested microservice in his tests. We wrote the models in a different module (image_capture_client) because image_capture_service is a Spring boot application; it is not possible to use it as a Maven dependency in our testing project because it does not allow access to its classes from other projects.

Image_capture_service is a Spring boot application that includes the REST API’s controller. This controller has three APIs: POST /capture for capturing images and storing the image objects with the image’s url in the database; GET /get-by-name which retrieves image objects from the database by their name; and GET /get-by-id which gets image objects from the database by their id.

The third module is Image_capture_tests. Here you can look at the pom.xml of this module. Highlights are detailed below.

Including a dependency for image_capture_client in order to use objects from image_capture_client model

Including Thucydides Jbehave plugin

Slf4j-simple — a wrapper of the logger implementation, usually log4j

Setting a start class for the application

Adding Maven failsafe plugin, designed to run integration tests.

Adding the Jbehave Maven plugin to run stories via maven goal as embeddables:

The project codebase of the image_capture_test module can be found here.

The stories of the Jbehave tests can be found in the resources directory of image_capture_tests.

Get_image.story example:

Each step mapped by its name to the code block inside GetImageSteps class of steps directory (see more examples HERE).

If you would like to run a specific story, you can mention the story-related path in findStoriesCalled method using ApiTestSuite constructor.

There are two ways to run your tests locally. You can either deploy your service and run ApiTestSuite against it, or you can build the project with Maven. When building with Maven, tests will run as part of the build; the build will fail in case of a test failure.

In order to demonstrate a dependency between microservices, we included the image_converter microservice in the project. Its structure is similar to image_capture. Upon code changes that alter another microservice, both services will be tested by the triggered Maven build action. Needless to say, all microservices should be up in order to do so. In the next example we changed the code of the image_converter to convert an image in a way that image_capture cannot implement. Now, no matter what, the converter will return the image with type jpeg, as you can see in the snippet below.

You can also see the output of the console after trying to build image_capture via Maven.

We would like to emphasise that the mechanism we described can also be implemented as part of CI/CD environments. We have integrated the tests into the microservices ecosystem which is managed in Docker,however, there other options.

Summary

In this article we describe a solution for testing dependent microservices both locally and as part of CI/CD processes. We chose JBehave and Thucydides because of their many advantages: They are flexible, licensed as open source resources, and provide out-of-the-box reports. It is also easy to debug and support Behaviour Driven Development that makes development more accessible and understandable. Since Java is a popular coding language and Jbehave is not a complex framework, this solution is not limited to expert developers. We choose to present the proof of concept by testing REST APIs microservices, but the idea is not limited these tests.