Autowiring instances of ProcessEngine beans in src/main/java without @SpringBootTest

Camunda 7 Topics Discussion & Questions
1

Hi @Ingo_Richtsmeier and camunda

Struck with ProcessEngineRule and it’s cfg.xml. Has been trying a lot to generate the HTML files for JUNIT coverage and was able to do. Got to know while using ProcessEngineRule can’t use @SpringBootTest as it uses default application properties file which can’t be used to get the ProcessEngineRule.

I have seen the developer mode of implementing JavaDelegate where autowiring of ProcessEngine,RuntimeService is done and is being used to set some variables etc.
Now the issue is these auto-wiring works When @SpringBootTest is used(Which is a conflict for ProcessEngineRule as it depends on XML configuration).

How can this be avoided ? for now i have changed the developer autowiring using DelegateExecution like delegateExecution.getProcessEngine(). Our goal is to autowire the same process engine generated by cfg.xml in the java code(Which is possible with annoations such as @TestPropertySource,@SpringBootTest)

Thanks in advance.

2

Hi @ravii,

you can take a look at this spring example: https://github.com/camunda/camunda-bpm-process-test-coverage/tree/master/test/src/test/java/org/camunda/bpm/extension/process_test_coverage/spring
In Spring there is currently the problem that class reports for coverage are not created. This is only possible if the ClassRule is created on class level. But since the rule is not instantiated with the engine until @PostConstruct, there is a problem here.

If you are interested in the coverage, take a look at FlowCov. We have a workarround for that problem. And It gives you even more insight and can be easily integrated into the build pipeline. At the moment it is in beta and there is no local viewer yet, but that will change soon. There are examples (including spring) of how to use it and you can find a great cheesecake process that is using FlowCov here.

3

@dominikh - Thanks for the reply. Issue with HTML files is resolved. Was able to get the HTML files as suggested by @Ingo_Richtsmeier. Now the issue is ProcessEngineRule is something which uses cfg.xml(to generate HTML files) .Normally if i use @SpringBootTest,@PropertySource it uses properties file to autoconfigure everything from the ApplicationContext and is a conflict here if i use only cfg.xml and the autowiring refers to null in such cases throwing NullPointerExceptions.

Later if migration is required from H2 to postgres and if annotations such as @Service,@Repository is used then even that refers to null.

I have asked the developer to remove autowiring and get the ProcessEngine from the delegateExecution using it’s getProcessEngine() for now. How to autowire everything from cfg.xml when using JUNIT to avoid nullpointer?

4

Hi @ravii,

I think you have misunderstood me. Therefore a little bit more detailed:
You can test your process in serveral levels. You can read more about that in the camunda best pratices here. Unit testing actually takes place in the first scope.

If you want to use Spring for that in combination with the coverage you should check this example. Then it is possible to autowire the Engine. Moreover you can put all the delegates and service-mocks in that spring context so they are available for the engine. Then you dont need the cfg.xml anymore, because the builder then uses the spring engine and does not create its own from the cfg.xml. If you want to use Spring-Boot you should provide the InMemProcessEngineConfiguration of the example i posted above.
When writing unit tests you have to consider the following:

  @Autowired
  ProcessEngine processEngine;

  @Rule @ClassRule
  public static ProcessEngineRule rule;

  @PostConstruct
  void initRule() {
    rule = TestCoverageProcessEngineRuleBuilder.create(processEngine).build();
}

You need to do it like that to use Spring with the coverage tool. But then class reports for the coverage are not created, due to the problem i mentioned in my latest post.

Unit testing should be possible in-memory for your pipeline so I would not recommend to move to postgres in that scope. You shouldn’t mix up integration and unit testing.

If all of this sounds too complicated to start with, think about going on without Spring and consciously mocking certain parts. There is a great community project for this. https://github.com/camunda/camunda-bpm-mockito.

5

@dominikh- Thanks for the detailed explaination. i’m understanding still and will try the suggestion. As discussed enginerule will be initilized using @PostConstruct in spring and may not generate coverage report.

I have seen the shared URL example https://github.com/camunda/camunda-bpm-process-test-coverage/tree/master/test/src/test/java/org/camunda/bpm/extension/process_test_coverage/spring and a file named ProcessTest.java which shows FlowCovProcessEngineRuleBuilder used in the same way as TestCoverageProcessEngineRuleBuilder in the @PostConstruct method. So how is it different from using the class which follows cfg.xml. However i have seen example using InMemoryProcessEngineConfiguration but the way it is initialized is same in both the methods.

Attaching the mobile view of GITHUB url as i can’t access GIT from this system.

Rule-Image
Rule-Image720×1280 257 KB

6

Hi @ravii,

I uploaded a very simple example of how to use the coverage with spring boot: https://github.com/dominikhorn93/camunda-spring-boot-test-example
If you are using Spring-Boot you should setup the rule with the pre-build process engine.
Take a look at the example, I hope that is what you are looking for :slight_smile: