Automated API testing for the KIE Server

In software development, much has been said about testing and there are many ways to think about it. In the context of agility and DevOps, automated testing is considered a foundation for the principles of flow and fast feedback. Considering the implementation of jBPM and Drools within a software delivery project, it becomes natural to think about how to support reliable automated testing for both stages of development and continuous integration.

The KIE Server is a standalone component that can be used to execute business processes and rules via a REST API interface. This article explores the concept of API testing where consumers are expected to interact with the APIs provided by the KIE Server. The test cases consist of HTTP requests and responses exchanged against a live server. Consequently, these test cases are completely agnostic to the technology behind the API, just like real consumers are expected to be.

Why API testing?

The API testing approach was previously described as agnostic, but what does that mean? Perhaps it's worth explaining by listing the benefits:

• Tests are decoupled from changes in the system under test as long as the API contract is satisfied.
• Higher confidence, as tests assert on exact upstream expectations.
• Independence, as tests can be maintained as a separate artifact.
• Scalability, as tests can be adapted to also assess performance.

What about unit testing?

Yes, unit testing is important and should not be neglected. There are well-established techniques in the jBPM and Drools ecosystem to unit test knowledge assets. Such techniques usually comprise of either plain JUnit or the test scenarios offered by Business Central (aka The Workbench).

However, there are challenges that unit tests cannot address, especially if JUnit is not an option for your project. In that case, you are limited to only what Business Central offers:

• Testing rule flows, where the combination of rules fired must be taken into account.
• Testing transformations that occur with the input and output of the REST API.
• Writing API testing even with no Java or JUnit skills.
• Testing API performance (did I mention performance testing already?)

Having said that, it is well known that unit tests are faster and simpler to write, maintain, and troubleshoot. Therefore, one should favor them whenever possible.

Example implementation with Postman and containers

If you read along to this point you must be looking for something concrete. Before we get started, Figure 1 illustrates what follows later.

Postman is a popular tool for creating and executing HTTP requests. Walking through the diagram, notice that Postman is a core component in this implementation. With it, developers write test cases that are grouped into collections and later exported to a native JSON format. This exported JSON collection is then used as an input to Newman, which is a powerful command-line collection runner for Postman. It allows you to run and test a Postman collection directly from the command line.

The system we are testing is Red Hat JBoss Enterprise Application Platform running the KIE Server, which has the KJAR deployed.

Finally, both Newman and JBoss / KIE Server are bootstrapped in Linux containers. This setup particularly enables:

• Fast provisioning of components.
• No need to worry about dependencies (NodeJS, Java, etc).
• No difference when executed local or in the CI agent (e.g. Jenkins).

Experiment

In this example, docker and docker-compose are used to simplify the user experience. They are, together with Git, the only pre-requisites to running through the steps:

$ git clone https://github.com/juliaaano/rhdm-quickstart.git && cd rhdm-quickstart 
$ docker-compose up --detach --force-recreate rhdm-jboss

Check the logs and wait for KIE Server to startup:

$ docker-compose logs --follow rhdm-jboss

Run the postman tests:

$ docker-compose run --rm postman

Notice it is possible to launch and build the containers directly with other tools such as Podman, Buildah, and Docker itself.

You can also build the container image locally, which is useful if you made any changes to the source code. This process takes a bit longer, especially in the first run when there is no Docker cache on disk. Additionally, authentication is required with Red Hat's container registry to access the base image:

$ docker login registry.redhat.io
$ docker build --file d.jboss.Dockerfile --tag juliaaano/rhdm-jboss .

Once a new image is built, repeat the step:

$ docker-compose up --detach --force-recreate rhdm-jboss

In the GitHub project you just checked out, there are instructions for how to run the same app with Spring Boot instead of JBoss EAP. Look over the project's README for more information.

The example above features a business rules application, so business processes are left aside. However, the elements demonstrated there should not change and are also applicable to jBPM. KIE-Server and Business Central are integral parts of the Red Hat Decision Manager (RHDM) and Red Hat Process Automation Manager (RHPAM) platforms.