Witing integrating tests for camunda BPM process

[sridhar_akella]

Hi,

we have decided to write integration test cases for BPM process.

Please suggest which will be better approach for camunda process,

Thanks,
Sri

[thorben]

Hi @sridhar_akella,

See this section of the documentation: https://docs.camunda.org/manual/latest/user-guide/testing/

For a more specific answer, please ask a more specific question.

Cheers,
Thorben

[garysamuelson]

In context to integration testing - I’ve found that running Camunda’s engine from within a test-case (i.e. user’s desktop) doesn’t fully reflect the server’s features/functions from an integration perspective. Meaning that you need to drive the process as it’s installed on the target platform:

1. BPM engine
2. process
3. various task implementations
4. integration dependencies
5. host platform configuration (the app’ container and machine itself)

Basically, you need to verify the server as it’s running in the host’s ecosystem as apposed to within JUnit… Goal is to test Camunda on the target environment - not the developer’s desktop. Assuming the build-admin and/or QA specialist will not have Camunda installed locally (i.e. CI cycles).

With this requirement in mind, I’ve been testing via Camunda ReST interface. A test case, in this context, though being initiated within JUnit, is invoking process+integration against an installed BPM engine. This way, the test-case drives the process as it’s intended to run on the host. And, this is critical from an integration perspective - tests include various SOA (and other) interfaces which may not be available outside the host.

I’ve recently been looking at Apache-Camel’s JUnit extension (the test-part of Camel) as this includes the ability for asynchronous testing: whereby we can both emit and receive events concurrently (as in simulating SOA interfaces). And, this feature allows for loading sets of events into the server to both observe the process itself in a more realistic setting (i.e. server/network saturation).

[StephenOTT]

@garysamuelson do you see all of your testing on the target platform being done through Rest APIs and something like PhantomJS (for simulating user tasks) ?

[garysamuelson]

@StephenOTT I’m not sure that anything beyond the ReST API is necessary for moving a token between tasks. Unless, however… you’re testing specific UI features such as JS libraries contained within the context of the browser’s JS environment (executing JS libraries - i.e. Chrome’s container).

I’m strict about only using java for Camunda task implementations - avoiding embedded script within the process model itself (the bpmn xml diagrams). I may have bits of script in the model - but only enough to evaluate expressions evaluating CDI java-beans.

And, if Camunda’s ReST API doesn’t cover your requirements, it’s relatively straightforward to simply write your own ReST API to fill in the gaps.

For example - if Camunda’s ReST doesn’t meet my needs, I typically add a JAX-RS implementation as follows:
NOTE: this is an arbitrary example because Camunda already has a ReST operation for sending a message. Problem though is that Camunda’s ReST “start-message” call has a data-cap of roughly 5k characters.

@Inject
private RepositoryService repositoryService;

@Inject
private RuntimeService runtimeService;

@Inject
private HistoryService historyService;

And then drive the necessary Camunda features directly via Java. Example of sending a message:

runtimeService.createMessageCorrelation(“start_message”)
.setVariable(“bpmApiMessage”, “myBpmApi_message_payload”)
.correlate();

[StephenOTT]

We have been avoiding java, but using external scripts.

[garysamuelson]

@StephenOTT Script-only? Understandably.
I see it as two camps… Generally. Scripts or Java. I’ve worked both sides of the “net”.

I used to author everything in Script - but, this was on a different platform. I migrated back to Java since JDK 1.7 - 1.8. Really exited about Java 1.8. Though a little concerned why Oracle is dragging their feet on JavaEE - if that makes a difference given openJDK. I was also somewhat of a JS-master with dojo (UI/Library framework). Since dojo fell out-of-favor I’ve moved on. It’s all getting so complicated - like medical specialists we’ve become.

But the question… is Java more like brain-surgery (wizard behind the green curtain) and JS-script the chiropractitioner (where the system meets the user)?

[StephenOTT]

We try to use JavaScript and fallback of Groovy as much as possible. Few spots where we use Java directly. But little as possible.

We do this because Camunda is just a embedded workflow tool for us. It is part of a bigger “platform” / use case where the users/configuration staff are using JavaScript. So trying to standardize as much as possible.

I usually find the learning curve for Java is high and the docs are difficult to read and understand for non-java devs.
Obviously if a complex task calls for Java, and we use it. But most of the ‘load’ is handed off through web services/service tasks/external tasks to another system, and camunda really just handles the “orchestration”