New test runner EZE (Embedded Zeebe Engine)

[saig0]

Is your feature request related to a problem? Please describe.
Running tests with Zeebe takes too long. Each test case starts test-containers for Zeebe and ZeeQS that take ~ 10-15 seconds. The time grows fast to minutes by adding a few more test cases.

Describe the solution you'd like
Replace the Zeebe test-container with EZE. The embedded Zeebe engine takes only a few milliseconds to start.

Describe alternatives you've considered
Reduce the time by reusing the Zeebe environment. But the downside is that there is no more isolation between the test cases anymore.

Additional context
The test runner queries the data from ZeeQS to retrieve the state and history. Currently, ZeeQS is also started within a test-container. In order to reduce the time, we need to eliminate this factor, for example, by starting ZeeQS directly, or add namespaces (i.e. multi-tenancy) to ZeeQS.

Related to/depends on camunda-community-hub/zeeqs#169.

[aivinog1]

Hey @saig0!

We are suffering from a very long test execution time too. I would like to add the EZE support here. But I think that we should split it into two parts:

1. We just add EZE support and restart the ZeeQS just like we do in the current tests. So, I think that we should extract the TestEnvironment interface with something like this:

interface TestEnvironment {
    val zeebeClient: ZeebeClient
    val zeeqsClient: ZeeqsClient

    val isRunning: Boolean

    fun setup()

    fun cleanUp()
}

And make the ZeebeEnvironment class implement it. Also, I will create the EzeTestEnvironment implementation of this interface and make this work.
2. In phase two we could introduce namespaces in the ZeeQS to be able not to restart it between test cases.

Also, I have thoughts about the implementation. If I understand correctly, we could eliminate ZeeQS because EZE already provided the needed interfaces to access the exported data. Maybe, the right way is to do something like this:

1. Heavily think about modularity in ZeeQS. Extract the GraphQL parts in the separate module, and make the code (importing the data in ZeeQS, processing it, etc.) available as Maven dependencies.
2. Reuse it where it is needed. Because running all Spring Boot Applications in the Docker container has so much weight, it loads in tens of seconds. I think we should consider the alternative :)

[saig0]

@aivinog1 awesome that you want to work on it. 🚀

The idea of splitting the environment sounds good. Or, we create a new runner for EZE, depending on the duplication and the new abstraction layers. A new runner may provide better separation and allow further improvements.

Heavily think about modularity in ZeeQS. Extract the GraphQL parts in the separate module, and make the code (importing the data in ZeeQS, processing it, etc.) available as Maven dependencies.

This is already the case (except for the application module). We could use only the data or importer modules.

It did so for Zeebe-Play.

Reuse it where it is needed. Because running all Spring Boot Applications in the Docker container has so much weight, it loads in tens of seconds.

Good idea. If we don't run ZeeQS in a Docker container, then we could access the repositories of ZeeQS directly.