[Testing] Solve problems because of Spring Tests running multi-threaded

With the current setup, workers run in a separate thread, even if started up within a test case, as they are constructed normally.

The multi-thread setup leads to issues when asserting state or waiting for idle, like:

1. Wired issues with the InMemoryEngine of Zeebe: https://github.com/camunda-cloud/zeebe-process-test/issues/110
2. WaitForIdle method on the InMemoryEngine does not work, as the workers are independent, leading to workaround like: https://github.com/berndruecker/camunda-cloud-zeebe-tests-playgorund/blob/main/src/test/java/io/berndruecker/playground/zeebe/tests/SimpleSpringBootTest.java#L75

 public void waitForCompletion(ProcessInstanceEvent processInstance) {
        Awaitility.await().atMost(Duration.ofMillis(1000)).untilAsserted(() -> {
            RecordStreamSourceStore.init(engine.getRecordStream());
            assertThat(processInstance).isCompleted();
            Thread.sleep(500L); // required to avoid https://github.com/camunda-cloud/zeebe-process-test/issues/110
        });
    }

This needs to be solved differently.

Still, my goal would be to allow workers to use the @ZeebeWorker annotation normally.

[berndruecker]

This was fixed with the latest zeebe-process-test 1.3.3 release. Thanks to @remcowesterhoud 🎉

[berndruecker]

Hi @pihme! Let me give you a quick gist here - but also happy to hop on a Zoom call to discuss!

I want to write a test case, that tests all process-related artifacts, which for me is the process model, and all glue code around it. If you look at https://github.com/berndruecker/camunda-cloud-zeebe-tests-playgorund/blob/main/src/test/java/io/berndruecker/playground/zeebe/tests/SimpleSpringBootTest.java you can see, that this simple uses the process model and then I could make assumptions on the side effects. In this case, I would just mock the REST-Client injected in https://github.com/berndruecker/camunda-cloud-zeebe-tests-playgorund/blob/main/src/main/java/io/berndruecker/playground/zeebe/tests/ServiceTaskAGlueCode.java#L16.

This is inline to how many customers write test cases with Camunda Platform, see https://github.com/berndruecker/camunda-spring-boot-amqp-microservice-cloud-example/blob/master/src/test/java/com/camunda/demo/springboot/OrderProcessTest.java#L103 as an example. There you test all surrounding glue code together with the process model - this gives you a good confidence that your process solution works. This is also described as “Scope 1” in https://camunda.com/best-practices/testing-process-definitions/# (just that so far I struggled to switch to single-threaded workers in spring-zeebe, which is kind of this issue).

Testing the adapters would be nice, but I don’t see many people doing this in isolation. Same for the process model. I find the sketched scope the most pragmatic approach to test all important aspects in one go - and thus I find it most likely that people are really doing it.