"Process Test Coverage" v0.2.9 and "Scenario" v0.2 released

Hi all,

I am happy to announce two community extension releases:

  • Camunda BPM Process Test Coverage 0.2.9 comes with bug fixes, a further investment into more robustness, and it enables testing in a pure spring environment, e.g. allows to re-use the dependency injected process engine in the test class for coverage. See an example of that here. Many thx to @lldata for the related pull request! (Btw I would in particular be interested in @zambrovski’s comment whether this resolves his most urgent requirements, too.)

  • Camunda BPM Scenario 0.2 comes with a further investment in robustness, too, enables in particular the interception of BPMN Conditional Event Waitstates, therefore catches up with Camunda BPM 7.6.x and introduces extensive Test Case Logging. The logging shows in detail in which steps your scenario runs through your process definition and also how the scenario execution fast forwards your process instance(s) into the “process future” when testing them. This looks like e.g.

| Started   receiveTask        'Wait for documents' (ReceiveTaskWaitForDocuments @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4)
* Acting on receiveTask        'Wait for documents' (ReceiveTaskWaitForDocuments @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4)
| Deferring action on          'Wait for documents' until 2017-01-25 18:10:21 (ReceiveTaskWaitForDocuments @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4 ...
| Fast-forwarding scenario to 2017-01-19 18:09:21
|-- Executing timer-transition   (BoundaryEventDaily @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4)
  | Started   boundaryTimer      'daily' (BoundaryEventDaily @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4)
  | Completed boundaryTimer      'daily' (BoundaryEventDaily @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4)
  | Started   sendTask           'Send reminder' (SendTaskSendReminder @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4)
  * Acting on sendTask           'Send reminder' (SendTaskSendReminder @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4)
  | Completed sendTask           'Send reminder' (SendTaskSendReminder @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4)
  | Started   noneEndEvent       'Reminder sent' (EndEvent_1 @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4)
  | Completed noneEndEvent       'Reminder sent' (EndEvent_1 @ DocumentRequest # dad1fecf-dda0-11e6-906e-7ebec62e68c4)
  | Fast-forwarding scenario to 2017-01-20 18:09:21
  |-- Executing timer-transition   (BoundaryEvent_2 @ InsuranceApplication # dacca880-dda0-11e6-906e-7ebec62e68c4)
    | Started   boundaryTimer      '2 days' (BoundaryEvent_2 @ InsuranceApplication # dacca880-dda0-11e6-906e-7ebec62e68c4)
    | Completed boundaryTimer      '2 days' (BoundaryEvent_2 @ InsuranceApplication # dacca880-dda0-11e6-906e-7ebec62e68c4)
    | Started   userTask           'Speed up manual check' (UserTaskSpeedUpManualCheck @ InsuranceApplication # dacca880-dda0-11e6-906e-7ebec62e68c4)

In the following you find the links to information about Camunda BPM Test Coverage as well as Scenario.



Very impressed with these new frameworks.

Hope you don’t mind my asking:

(1) I noticed a requirement for ProcessCoverage InMemProcessEngine Configuration

Is it possible to use the framework while driving a JUnit test suite against ReST APIs? Reason I ask is that the in-memory configuration doesn’t address dependencies (and risks) associated with running a process within its actual ecosystem. This means, I need to launch a process where it lives within a domain associated with various things such as SOA, DB, etc…

In the past I’ve depended on the Apache Camel test framework as this provides reasonable access to such things as routing, concurrency, multi-instance (and control/monitoring of)…

Hi Gary, good to hear that you like it!

The answer to your question is currently no. Both frameworks address the more “unit”-test oriented aspects of process definition testing and not the more “integration”-test oriented aspects and are wired to use the Java API, and typically (but not necessarily) use an “In Memory” H2 backed ProcessEngine.

Having said that I want to add that I find your comment quite inspiring. Principally, the idea of both frameworks (to define and run “scenarios” as well as “visualise” their actual execution pathes) could be applied to the more “integration” oriented testing needs, too. However, I guess that the effort necessary to fully think and work through such a thing would not be a piece of cake.


The visualizations would be a very nice prize. I’ll see if I can mix-and-match a framework to integrate the two. But, as you said, it’ll be a non-trivial effort.

Driving this approach is a need to visualize performance with a BPM/BPMN perspective. For example, answering the sort of question:

what happens if our SOA infrastructure is saturated with an increasing load of f(x) = e^x events.

Inspirational - absolutely!

Initial thoughts include the application of a stand-alone framework. I personally like the hawtio approach along-side the Jolokia library (JVM/JMX agents). This way we have Camunda essentially happily existing within its own ecosystem… though getting pummeled with a significantly increasing event load targeting the various BPMN-Task and Event implementations. And, with hawtio, we have multiple views into various SOA sub-systems.