Camunda Integration tests extremely slow

[stephenm]

Hello,

I’m trying to optimise a Spring boot project, which uses an embedded Camunda Engine. The problem is that we have about 12 integration classes and doing a full build results in the integration phase taking 8 minutes and 16 seconds and only gets worse with each addition.

We are using 7.16.5 and the base class has the following:

@SpringBootTest()
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@ActiveProfiles(value = "ci")

These tests don’t even use camunda, but instead exercise the spring web controllers, it just happens that camunda is started up each time. So disabling it at this point would be fine, but eventually for the workflow tests I’ll need it, which can take the form of another suite of tests.

Are there any recommended strategies, best practices to deal with this problem?

Stephen

[Ingo_Richtsmeier]

Hi @stephenm,

I would define an additional profile without the camunda-bpm-spring-boot-starter and with a separated application.yaml that doesn’t include the engine configuration.

And use this profile for the test.

Hope this helps, Ingo

[stephenm]

@Ingo_Richtsmeier

I would define an additional profile without the camunda-bpm-spring-boot-starter and with a separated application.yaml that doesn’t include the engine configuration.

And use this profile for the test.

Hello Ingo,

Thanks for the swift response and for the info. I’ve tried to add/eliminate a number of things such as failsafe multithreading and removing @DirtiesContext to deal with the liquibase lock (nothing to do with camunda so far…). But with that approach I get: ‘Start Process Application Service’: Cannot register service org.camunda.bpm.platform.job-executor.process-application:type=camundaConfig so I’d need a dynamic name generated for each test.

It may well be better to take the approach you had outlined. I’d still like to have workflow tests for completion, but even with those camunda tests, I’d like to be able to fork them into multiple threads to speed things up.

Stephen

[fml2]

Can’t you restrict the beans that get loaded at application startup? I.e. exclude the process engine from being loaded. This can be done via annotations in the test, just look for the docs on the web.

[stephenm]

I tried this last night but found myself going down a rabbit hole with autowiring errors. I went on to using @MockBean for things like the Runtime service, but again that led to further errors.

[thorben]

@stephenm

Thanks for the swift response and for the info. I’ve tried to add/eliminate a number of things such as failsafe multithreading and removing @DirtiesContext to deal with the liquibase lock (nothing to do with camunda so far…). But with that approach I get: ‘Start Process Application Service’: Cannot register service org.camunda.bpm.platform.job-executor.process-application:type=camundaConfig so I’d need a dynamic name generated for each test.

Not sure it’s the right direction here, but this documentation could help you with this particular problem: Developing and Testing Spring Boot Applications | docs.camunda.org