So our workers are in different projects and repos. We deploy the workflows in runtime. So now wondering how should we tests our workflow, I mean the automated tests. The requirement is
Run a workflow
Asserts some messages being set by the workers
Sorry for so general question, but I want to know how people testing their workflow
Hi,
I don’t know if it’s relevant for your question, but we use Zeebe in a .NET distributed system and we have different levels of test:
we unit test workers independently (of course)
we have another level of test involving all workers of a workflow and using a stub. This is exactly what is done by the C# client tests using a GatewayTestService
and finally, we have an integration test involving a simple Zeebe cluster deployed in a Docker container. The test setup drives the Docker using an appropriate library. This is also exactly what is done by the C# client tests using the ZeebeIntegrationTestHelper. This last test involves the deployment of the BPMN.
If the worker itself has some external interaction (e.g. db access) it is tested independently.
Hope it helps.
Thanks @xavier , this is exactly I was looking into. I think we should have a sample project which includes all these listed by you. And those are the types of test in our project as well, just that we are in Kotlin. Now I have to check if Java Client provided equivalent functionality.
btw, do you have all the worker in a same project and then you run the integraiton tests in that project or ?
In our case the workers are all in differnt project, and now I thinking if that is something people do it and if yes then how do they deploy and run tests .
The Java ecosystem has at least the equivalent but I would expect it to be richer. I must admit that I have read the Java zeebe client as a source of inspiration.
Concerning workers, they are independent units of deployment mostly because of scaling (with different licensing constraints). So they are organized in different projects. But of course we cannot test them this way because it would be much too complicated: so we create an ad-hoc system (SUT) with a dedicated assemblage of required workers for a workflow.