Running Camunda BPM Process Tests with Container Managed CDI Beans
BPM projects often start with a simple process model. But from experience the process model complexity grows with the project time and it is needed to test the interaction between the process model and the referenced implementation. Its a good practice to use mocks during testing to remove dependencies from frameworks like Camunda BPM or service calls to systems, which are not available or in turn have a lot of dependencies. Camunda BPM has a out-of-the-box mechanism,which is described later in this article. NovaTec developed a Bean Testing framework for full CDI Bean testing without an Java EE application server which is successfully used in many projects.
This article describes how it is possible to use Bean Testing for loading beans and mocks in the context of CDI implementations. This approach doesn’t aim for unit test implementation. It is kind of a component test without the service calls. They will be run during the integration tests. A great side effect: You can use and test with the full CDI API, like injections of interceptors and other mechanisms. This article will compare these two concepts.
Most of the Camunda BPM based projects are implemented with frameworks like Java EE or Spring. With these frameworks it is possible to switch between mocks for service implementation and the real implementation with an alternate bean declaration. This test setup will not run with plain classes but with beans of Spring or CDI / Enterprise Java Beans (EJB). This article will describe only the testing possibilities with Camunda BPM process models. For more information about testing in Camunda BPM you can read the following guide: https://docs.camunda.org/manual/latest/user-guide/testing/
The statement “complete(…)” handles the human tasks and integrates the relevant data for continuing the process flow. When testing a process you should never implement logic nor service calls into the delegates, because if you do so, it is very hard to mock not needed/wanted classes without using Java Reflections or a special framework.
Camunda BPM applications are typically implemented in the shared server concept. There it is possible to run the CDI, Spring or plain Java classes as references in the task implementations. Most of the Camunda BPM applications are based on CDI or Spring beans. (If you consider plain java classes be aware that the classes can not be replaced with other ones, because the link in the process model is hard coded. If you want to provide an alternate implementation you have to add a testing process with the mocked implementation. So this is not a really good idea to provide a plain java implementation.)
Camunda Out-of-the-Box Mocking
Camunda BPM provides an out-of-the-box implementation for providing beans in the defined expressions of the BPMN model. You can add all needed classes to the camunda context with the command “Mocks.register(<expression>, <class instance>);”. But be sure, that you mock all services with a mocking framework like Mockito. The following listing shows the pizza example with the mocked service call:
You have connected the CDI container to the engine and you can start testing. If you have problems with resolving the beans, be sure that you have placed the “beans.xml” file in the “src/main/resources/META-INF/” folder. Otherwise the CDI container cannot find the bean classes. For mocking your beans, it is needed that you configure CDI alternatives in the “beans.xml” file in your test directory “src/test/resources/META-INF/”:
With this approach you can decide: Insert your mocks and logic via the Camunda BPM mechanism “Mocks.register(“sampleService”, new MySampleService());” or you use this Bean Testing approach to insert your implementation into the Camunda BPM context. If you want to register your mocks and logic manually you have to make sure that you do not forget any. Also, you need to instantiate all beans and mock all not wanted/needed classes. In my opinion, it is easier to use the approach with Bean Testing, because you create a link to Camunda BPM once and insert your mocks in your testing “beans.xml”. Everything else will be done by the CDI container. You can also use the full functionality like interceptors in your tests like it is implemented in the Bean Testing example.
If you want to see how your newly written bean testing of camunda process application progresses, you can show the process test coverage in a html file with the “camunda-bpm-process-test-coverage” extension (see here: https://github.com/camunda/camunda-bpm-process-test-coverage). It will show the complete process flow, with the green colored pass through nodes.