Best Practices for Migrating TESTS from Camunda 7 Embedded to Camunda 7 Run with External Task Client

My customer is currently evaluating migrating to Camunda 8. Their application currently uses Camunda 7 embedded. To minimize risk and gain a deeper understanding of running the workflow engine as an external service, they plan to initially migrate to Camunda 7 Run/Platform, using an external task client. As a result, the logic currently implemented as JavaDelegate handlers will be shifted to handlers implementing ExternalTaskHandler.

We are currently encountering numerous questions regarding test migration. In the embedded environment, tests are structured at all levels as described in the Camunda docs: Camunda Testing Best Practices. However, having a Spring Boot service that only uses camunda-bpm-spring-boot-starter-external-task-client does not support this. The examples provided by Camunda, such as the external-task-client example, lack any tests, which is quite frustrating.

What would be the right approach here? The customer aims to conduct tests covering the entire process scope (logic defined in the model) along with the code from the handlers, as is feasible with the embedded version. Thx.

Hi @Adam_Boczek,

you can still use your JUnit tests and use


to continue the process execution. Here is a simple example: camunda-7-code-examples/snippets/external-task-security-example/secure-spring-boot-process-engine/src/test/java/com/camunda/consulting/secure_spring_boot_process_engine/ at e538d6aff95fd4a69b8cca5052ee6bff46764998 · camunda-consulting/camunda-7-code-examples · GitHub

The API provides the option to pass variables with completing the task.

To test the worker code, you can mock the ExternalTask and ExternalTaskService object.

Hope this helps, Ingo

1 Like

Hi @Ingo_Richtsmeier I have another question in this context. Is there a way to trigger a handler implementing ExternalTaskHandler so I can simulate a subscription to the topic and run actual handler’s code, rather than just using complete() ? This would be similar to how we currently use Mocks.register() to test our glue code, where we can register any object (not only an empty mock) that implements JavaDelegate .

Can’t you just instantiate the handler and call it? I.e. you’d test it as a unit.

Clear, we do it currently using JavaDelegates, but we would like to test the flow with the handler code which reacts, for example, to variables that are set during the process flow.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.