gclaussn
commented
2 weeks ago hi @bennobuilder,
on branch issue/192 (see commit) I added an example process with a multi instance call activity that uses a collection expression ${elements} and element variable element. A test starts a test case with variable elements=["a", "b", "c"] and verifies the loop count as well as the variables at the call activity within the multi instance.
it is a bit tricky to test the local element variable, used within the multi instance.
in the verify method of the call activity handler of the multi instance a ProcessInstanceAssert (here named piAssert) is provided. but it can only be used to assert variables that are on process instance level, e.g. elements. to verify local variables, like the element variable, the local variables of the related exectution must be retrieved. to do this, the execution ID is required. therefore the historic activity instance of the multi instance body must be found.
tc.handleCallActivity().handle(0).verify((piAssert, callActivityDefinition) -> {
piAssert.variables().containsKey("elements"); // assertion of process scoped variables only (e.g. collection)
// find process instance of test case, e.g. by business key
var pi = tc.getProcessEngine().getRuntimeService().createProcessInstanceQuery()
.processInstanceBusinessKey("bk")
.singleResult();
// find historic activity instance of call activity in multi instance scope
var historicActivityInstance = tc.getProcessEngine().getHistoryService().createHistoricActivityInstanceQuery()
.activityId("multiInstanceCallActivity#multiInstanceBody") // BPMN element ID + #multiInstanceBody
.singleResult();
// get local variables (including element variable of collection) of related execution
var localVariables = tc.getProcessEngine().getRuntimeService().getVariablesLocal(historicActivityInstance.getExecutionId());
assertThat(localVariables.get("element"), equalTo("a"));
});when the element variable is propagated to the subprocess via delegate variable mapping, in mapping propagation or in mappings, the variable value is much easier to assert.
tc.handleCallActivity().handle(0).verifyInput(variables -> {
assertThat(variables.getVariable("element"), equalTo("a"));
});
tc.handleCallActivity().handle(1).verifyInput(variables -> {
assertThat(variables.getVariable("element"), equalTo("b"));
});
tc.handleCallActivity().handle(2).verifyInput(variables -> {
assertThat(variables.getVariable("element"), equalTo("c"));
});this example shows that a multi instance call activity with collection expression is supported.
regarding your test, I'm not sure what DelegateMock is doing. maybe the emails variable is not set correctly.
i hope the example helps. if you have more questions, feel free to ask.
best regards!
bennobuilder
I’m currently working on a test case using BPMN-Driven-Testing and encountered an issue while trying to test a multi-instance subprocess configured with a collection (
camunda:collection, see image).In my test, I expect the
verifyLoopCountto reflect the size of the collection (in this case,2for a list of two emails), but it always returns0. The variables are being consumed (-> to verify ProcessInstance contains variableemailsbut empty).Is there support for testing
camunda:collectionin this context (couldn't find any test) or is only loop cardinality supported. An example or guidance would be appreciated.Thanks :)