Now that we have continuous integration tools and can automate the majority of development tasks, it's about time we added automated process testing to our bag of tools to ensure our processes will not break with bug fixes or when adding new features.

A typical BPM process includes integration to back-end systems and tasks that users need to perform. As we develop the solution, we split testing of these components into three categories:

• back-end integrations
• process models and
• user interfaces

Back-end integrations

When developing backend services that will be consumed by our processes, automated testing is essential and usually straight-forward. SOA Suite provides tools to create test suites, and if we are building web-services then any tool that can invoke the service and analyse the response. We can run test suites as soon as changes are committed in our repository - or trigger a test suite using a commit hook to ensure changes don't break anything. Should that happen, the commit is then aborted.

Font-end UIs

For front-end UIs, it might get a bit trickier but automated testing can be done as well. If the UI is developed using ADF, then Oracle provides an ADF testing solution known as Oracle Application Testing Suite (OATS), but other tools such as Selenium and CasperJS can also help. If developing with other frameworks such as Angular JS or React then things are a bit easier since these frameworks already provide facilities for testing. In the specific case of React, developers can build isomorphic apps that can be run either on the client or server side.

Business processes

Finally we are left with business process testing. In the early stages of process development, back-end services can be replaced by mock-up services created for instance with soapUI. This allows developers to trigger a process and let it run - until it hits the first human task.

Ideally, we don't want any human interaction when running a test, we are just interested in the test results. So how do we go about submitting a task? it's quite simple, actually: we "ask" a third-party application to do that for us. The first step is to be notified when a human task is created, which can be done by configuring a callback class and overriding the onAssigned method. The next step is then to send this task to our 3rd party app, whicn in turn will submit the task using the BPM/Human Workflow APIs.

The initial proof of concept built using this idea proved successful, which encouraged us to pack it into a solution named HTTF that can be used in any BPM project.

What is HTTF

It is a solution that helps testing Oracle BPM 11g/12c business processes by automating the submission of human tasks. Developers configure the different human task payloads and outcomes through a REST API. At the process level, they need to configure the callback class in the Human Tasks and finally trigger the business process to test.

The solution is split into two parts:

• a Java EE application that receives human tasks, run groovy assertions to verify their state if desired and then updates their payload (optional as well) and outcome
• test suites scripts written in JavaScript that run in Node.js, coordinating the end-to-end testing: from task configurations to process end-to-end tests

Side note: you might be wondering why use Node.js at all. The answer is quite simple: all HTTF functionality is exposed as REST services, which means that any app that can invoke REST can be used to create test suites. It just happens that there are certain JavaScript libraries such as Mocha and should.js that simplify writing tests.

Different tests can be performed at different points in time

1. When a Human Task is assigned: the task and its payload can be passed on to a Groovy script (part of a task configuration) that runs assertions to verify the current state in the process. Should any assertion fail, the assertion error will be added as a comment to the BPMN instance which in turn will be suspended so the test suite will consequently fail. In addition, Groovy scripts can modify the outcome and payload to use during task submission to handle more dynamic cases.

2. When the test unit has completed: the HTTF API exposes a REST service to request the instance audit trail, which can then used to compare it against a pre-defined path that the instance should have followed for the test to be successful. And since we have the full audit trail (in JSON format) we can fetch as much data as desired from the other composite components as well.

Not all tasks are created equal

When we store task configurations in the processor app we need a unique key to identify them. There might be the case that the same human task is used in two different places and we want two different outcomes for the same task. How can we accomplish this?

To store a task configuration, we use a 'discriminator' value. This value is obtained from evaluating an XPATH expression against an XML representation of the task, allowing us to extract a unique key. By default, the processor uses the title of a task as a discriminator. In this way, the very same human task can be used as many times in the process models as desired provided the developer uses a different title in each task.

If for some reason the task title is not a good fit, we can always change the expression and evaluate even the task payload to find a unique value that allow us to differentiate the same human task in the process.

Running a test suite

A complete automated process test suite consists on the following steps:

1. a set-up configuration test suite that includes clearing the current HTTF configuration for a specific composite, then setting the task discriminator, tasks and credentials and finally a test case to verify the configuration has been stored properly
2. a process suite that includes a process instance creation test case, a wait test case that will finish when the instances finishes its execution, an instance status check and finally one to ensure the instance has completed the required steps in the process.

It is worth mentioning that HTTF can be enabled or disabled using either JMX or the REST API. This allows developers to run tests manually without intrusion from the framework, which would otherwise submit human tasks automatically. A best practice would be to enable HTTF in the before hook of a process test suite and disabling it once it has completed (after hook).

Conclusion

Automated business process testing brings in an additional step towards quality of business process development. By using a solution like HTTF, developers can ensure that adding new features or making changes in existing processes will not break their existing solutions. Tests are easy to create and execute, and even minimal testing such as instance audit trail cases can help ensure the quality of a release.