Work with processes started by the scenario

[Benjoyo]

Given a diagram like that

...how can I work with Process 2 using scenario?

Message correlation could happen by expression or by a JavaDelegate. I can verify that Process 2 is indeed started correctly and waiting at the user task by using processInstanceQuery(). Is there any way to perform scenario based testing on this instance just like with the main process?

Is this what is meant by #3 ?

Thanks in advance

[martinschimak]

Hi @Benjoyo I am excited about your interest. This is exactly what is meant by #3. It is not yet supported and kind of the last missing piece in the puzzle of testing complicated scenarios. Starting several instances, which interact at a later point, is already possible btw. The feature is probably not supertricky to implement, but you really never know before starting. :) As I am currently doing some serious work on the library, I am inclined to implement this ... would you be interested in this feature? If yes, would you be able to "acceptance test" some alpha version of it? Do you have interesting scenarios to use such a feature with? All the best, Martin.

[Benjoyo]

Hey @martinschimak thank you for the quick reply.
To be honest, I am just starting with Camunda and have a toy project in which I use a construction similar to the above to spawn a user task that „survives“ the main process.
As part of my exploration I am trying out the different test libraries and compare „classic“ tests using bpm assert and bpm mockito with camunda-platform-scenario and found the scenario based testing to be very elegant for complete path tests. So I would love to use this library in future projects and would be happy about any additional functionality.

I can’t say yet how often this feature really would be required, I guess at least in my case it would be fine to test the flow in the second pool separately. But in other cases it would be cool to test cooperating processes together I think.

As I am just beginning I can’t test the feature in complicated scenarios yet, but I would be happy to try it out anyway if it helps :)

Thanks and best regards
Bennet

[martinschimak]

@Benjoyo It should already work. If you check out this branch https://github.com/camunda-community-hub/camunda-platform-scenario/compare/feature/work_with_processes_started_by_the_scenario and mvn install it locally, you can test it with the 2.0.0-SNAPSHOT dependency. Please note the new group id, which is now org.camunda.bpm.extension.scenario and the new artifact id, which is now camunda-platform-scenario-runner.

Here is basically what you need:

Mockito.when(process.runsProcessInstance("OtherProcess")).thenReturn(Scenario.use(otherProcess));

If you have questions or feedback just get in touch with me here!

[Benjoyo]

@martinschimak Sorry it took so long, I just tested it and it seems to be working just fine, thank you!
I have a question that is only partially related I guess. I have the following processes, similar to the above diagram, but with a return message and an event based gateway, that models a timeout for the newly started process:

I am testing the happy case when the refill stock user task is completed in time (<4h) and the bad case when it is not completed in time (>4h), using the new feature. I am not sure how to stub the event based gateway correctly (waitsAtEventBasedGateway). In the first (happy) case, it seems to be fine to not stub it at all. In the second case I get:

java.lang.AssertionError: Process Instance {order:2:23, 20} waits at an unexpected EventBasedGateway 'gateway_stock_refilled_or_timeout'.

So then I just stub it with an empty body and it works. Note that I am using the actual correlation code in the delegates in my tests. Is this expected, or how should I handle event based gateways correctly?

[martinschimak]

Hi Benjoyo,

a design decision that I made with scenario is, that every "natural" wait state in a process has to be explicitly stubbed. The reaason behind it is, that a test should break when we do not have dealt with a waitstate at all, in other words we haven't even defined a "default, happy" way how to complete it successfully. If we add e.g. activities to a process, we should at least add this happy completion stub to our test case and all scenarios should work again.

Now, an event based gateway is also such a "natural" wait state, meaning it is no technical decision to make it async. It is always async in the sence that the process state is persisted and waiting for another trigger coming from outside. Therefore it also, like all other waitstates, has to be stubbed. At the same time the event based gateway is a bit different than normal task waitstates (user tasks, external tasks), in the sense that we do not necessarily need to do anything there, because the trigger comes from somewhere else in the scenario. Stubbing a waitstate with an empty body really just means: continue to wait at this waitstate. This can be legitimate because the trigger to move on comes from somewhere else, or just because we want to test just a part of the model. But we also have the possibility to model the trigger in the gateways stub itself, if we do not have any other possibility, like e.g. assume you test the first process "standalone", without adding the "Refill stock" process to your test scenario. Now you need to trigger the message "Stock refilled" coming from outside explicitely in your waitsAtEventBasedGateway stub.

A question remains: why does your error message (which is really the default error message reminding the developer to always stub every natural waitstate) just show up in the second scenario. I assume that the reason is that the scenario runner does not realize that the stub is missing, because it doesn't need it. The error message always only shows up when the runner tries to deal with a stub. In your first scenario it seems to trigger the outside message even before it looks for the waitsAtEventBasedGateway stub. This is a bit unfortunate, because it contradicts the design decision "always stub all your wait states explicitely" mentioned above. I am therefore thinking about validating this at an earlier point, but I am unsure whether it is feasible.

Anyway, thank you VERY much for your feedback. This is exactly one of the issues which can basically only pop up when testing processes collaborating "on eye level" with messages, and I guess not so many people have done it so far. And so far it only was possible to start several processes interacting later, but it was not possible to start another one with the first one, which is probably the more often needed variant. Benjoyo, just in case you have more such scenarios or just more questions, please don't hesitate to get back to me! :-)

All the best,
Martin.

[Benjoyo]

Thank you for the explanation, that does make sense! I will get back to you if I have any more problems or questions, thank you for being so kind. Right now, however, everything seems smooth :)

[zharkov-ruslan]

@Benjoyo It should already work. If you check out this branch https://github.com/camunda-community-hub/camunda-platform-scenario/compare/feature/work_with_processes_started_by_the_scenario and mvn install it locally, you can test it with the 2.0.0-SNAPSHOT dependency. Please note the new group id, which is now org.camunda.bpm.extension.scenario and the new artifact id, which is now camunda-platform-scenario-runner.

Here is basically what you need:

Mockito.when(process.runsProcessInstance("OtherProcess")).thenReturn(Scenario.use(otherProcess));

If you have questions or feedback just get in touch with me here!

Hi, @martinschimak! I also faced a similar problem - working with a process started from a scenario. I was pleasantly surprised that this issue has already been resolved, but why is there still no release of the library with this feature. I have already tested this solution locally, but I have a big wish for your to make a release with this feature, it is very useful and necessary for full coverage of collaboration processes with tests. Thank you in advance!