Disable JobExecutor in Tests

Camunda 7 Topics Discussion & Questions
1

Hi guys…

According to docs:

Job Executor in a Unit Test

For unit testing scenarios it is cumbersome to work with this background component. Therefore the Java API offers to query for ( ManagementService.createJobQuery ) and execute jobs ( ManagementService.executeJob ) by hand , which allows to control job execution from within a unit test.

But I’m not sure exactly how to configure that. I’ve tried the following code but it’s still running jobs in background.

public void preInit(ProcessEngineConfigurationImpl cfg) {
    cfg.setJobExecutorActivate( false );
}

How can I disable any async execution and force jobs to be executed manually?

2

It seems like you are still starting the server. Are you testing from within jUnit4 as described here: Testing | docs.camunda.org ?
Then the job executor is already disabled. You don’t need to configure anything in the camunda.cfg.xml under src/test/resources

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
  <bean id="processEngineConfiguration" class="org.camunda.bpm.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration">
    <property name="history" value="full" />
    <property name="expressionManager">
      <bean class="org.camunda.bpm.engine.test.mock.MockExpressionManager"/>
    </property>
    <property name="processEnginePlugins">
      <list></list>
    </property>
  </bean>
</beans>

Instead you now need to " execute jobs ( ManagementService.executeJob ) by hand , which allows to control job execution from within a unit test."

I highly recommend to use bpm assert in your jUnit test. It reduces the test code significantly

Then you would move the job forward like this:

    List<Job> jobList = jobQuery()
            .processInstanceId(processInstance.getId())
            .list();

    Assertions.assertThat(jobList).hasSize(1);
    Job job = jobList.get(0);
    execute(job);

or simply with bmp assert using:

asserThat(processinstance)…
execute(job());

another example:

    ProcessInstance pi = runtimeService().startProcessInstanceByKey("ParallelProcess");
    assertThat(pi).hasPassedInOrder("StartEvent_1", "ExclusiveGateway_1");
    Job job = managementService().createJobQuery().orderByJobPriority().desc().list().get(0);
    execute(job);
1 Like
3

Good point…

Indeed, today I’m not using this technique but my tests start like this:

RunWith(SpringRunner.class)
@SpringBootTest(classes = { HunterCommanderTestApp.class,
		TestConfigurations.class }, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class MyTest {
    ....
}

That’s because, besides the whole engine, I’m still have some spring beans that must be available for the tests to succeed… Would them be loaded using the example you mentioned?

Besides the fact that I’m probably not using the best way to test, shouldn’t the configuration I mentioned disable job executions anyway?

4

In the first stage you want to keep the test environment as lean as possible and focus on testing the process. in the second stage you would bootstrap the Spring environment and include the actual services in the test, but have the job executor running (aspects related to it have already been tested in stage 1).

This article explains the different stages of testing and how to deal with spring beans, business services, job executor, etc.

testingScopes
testingScopes1354×897 83.8 KB

if you absolutely must do so, the job executor can be disabled in your application.yaml / properties using the property:
camunda.bpm.job-execution.enabled=false