Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

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:
  2. WaitForIdle method on the InMemoryEngine does not work, as the workers are independent, leading to workaround like:
 public void waitForCompletion(ProcessInstanceEvent processInstance) {
        Awaitility.await().atMost(Duration.ofMillis(1000)).untilAsserted(() -> {
            Thread.sleep(500L); // required to avoid

This needs to be solved differently.

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

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

berndrueckercommented, Feb 3, 2022

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

berndrueckercommented, Dec 21, 2021

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 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

This is inline to how many customers write test cases with Camunda Platform, see 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 (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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Testing Multi-Threaded Code in Java - Baeldung
We'll build a simple use case and try to simulate as many problems related to concurrency as possible.
Read more >
How should I unit test multithreaded code? - Stack Overflow
Probably the best way to test code for threading issues is through static analysis of the code. If your threaded code doesn't follow...
Read more >
How should we unit test multithreaded code? - Medium
We write multithreaded code to run programs concurrently. Multithreading means multiple parts of the same program running concurrently.
Read more >
Testing Multi-Threaded and Asynchronous Code
Testing Multi-Threaded and Asynchronous Code · Go Parallel. The first step is to kick off whatever threaded action you wish to test the...
Read more >
Tests in multi-threading environment with JUnit
Learn 84 ways to solve common data engineering problems with cloud services. ... Through this article we'll discover how to write JUnit tests...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found