Run the First JUnit Test

Goal

The goal of this lab is to build your first JUnit test case for a BPMN 2.0 process with the help of the camunda-bpm-assert library. You will modify the process to run from start to finish without interruption and then you’ll create a JUnit test to see if the process behaves as expected with the data used in the test. You add configurations to the test engine and it’s logging output.

Short description

  • Strip down the process to the happy path. Morph the user task to a manual task.
  • Prepare your content assist to the camunda-bpm-assert library.
  • Add the required dependencies to spring-boot-starter-test, camunda-bpm-junit5 and camunda-bpm-assert.
  • Prepare your IDE to handle the static imports of camunda-bpm-assert.
  • Create a JUnit test and start a process instance with the variable to approve the tweet. Assert that the process instance is ended right after the start.
  • Add a configuration file for the process engine picked up the JUnit rule to use a in memory database.
  • Run the JUnit test to see the green bar. Check the output of the scipts in the console.
  • Have a look at the Camunda Platform Assert Library User Guide to get more information about the test library.

Detailed steps

  1. For the first JUnit test, the plan is to start a process instance and have it run through to completion, approving and ‘publishing’ the tweet. To do that we need to modify the modeled process. Change the Review tweet task to a Manual Task using the Context Pad. By making an activity a Manual Task it won’t stop at Review Tweet and wait for a person to complete it, rather it will simply move on to the Approved? gateway. As part of the test we’ll set a variable for ‘approved’ in a HashMap before starting a process instance.

  2. Add the required dependencies to the pom.xml, ideally after line 83 which says <!-- Add your own dependencies here, if in compile scope, they are added to the jar -->

        <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-test</artifactId>
          <scope>test</scope>
        </dependency>
        <dependency>
          <groupId>org.camunda.bpm.extension</groupId>
          <artifactId>camunda-bpm-junit5</artifactId>
          <version>1.0.2</version>
          <scope>test</scope>
        </dependency>
        <dependency>
          <groupId>org.camunda.bpm.assert</groupId>
          <artifactId>camunda-bpm-assert</artifactId>
          <version>12.0.0</version>
          <scope>test</scope>
        </dependency>
    
  3. Prepare your IDE to handle the static imports of camunda-bpm-assert and assertJ. In Eclipse go to Window > Preferences > Java > Editor > Content Assist > Favorites > New Type… and add the following types: org.camunda.bpm.engine.test.assertions.ProcessEngineTests and org.assertj.core.api.Assertions. Also, go to Window > Preferences > Java > Code Style > Organize Imports and set “Number of static imports needed for .*” to “0”. IntelliJ should pick up the pom.xml updates and prompt you to import the changes.

  4. Open the JUnit test class from the folder src/test/java and inspect the content.

  5. Add the static imports for the Assertions and camunda-bpm-assert support into the import section of the class:

    import static org.camunda.bpm.engine.test.assertions.ProcessEngineTests.*;
    import static org.assertj.core.api.Assertions.*;
    
  6. Add the process to test with the

      @Deployment(resources = "your bpmn file.bpmn")
    

    annotation. The annotation has to be added to the testHappyPath method. Fill your file name into the resources.

  7. Add the ProcessEngineExtension as a JUnit 5 extension to the test class.

    @ExtendWith(ProcessEngineExtension.class)
    public class ProcessJUnitTest {
    
  8. At the start of the test code, we create a Map of type String, Object to use to put in our variables. Then we use the runtimeService() API to start a Twitter QA process instance using the ID (aka ‘key’ as you’ll see in the API call below) of the process template (TwitterQAProcess). We also provide the variables HashMap as an argument to the method. Finally, we utilize our assertion library to make sure that our process has indeed completed.

        // Create a HashMap to put in variables for the process instance
        Map<String, Object> variables = new HashMap<String, Object>();
        variables.put("approved", true);
        // Start process with Java API and variables
        ProcessInstance processInstance = runtimeService().startProcessInstanceByKey("TwitterQAProcess", variables);
        // Make assertions on the process instance
        assertThat(processInstance).isEnded();
    

    The complete class can look like this example.

  9. The process engine used in the rule in the JUnit test above needs to be configured. To do this, open the file named camunda.cfg.xml under src/test/resources and fill it with the content below. This configuration uses an in memory database, emits a full audit (history) trail, uses a configurable expression manager (mocks), and has a placeholder for further extensions (plugins).

    <?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>
    
  10. As spring boot defaults the logging level in tests to DEBUG (which is verbose), you can create a logging configuration at src/test/resources with the name logback-test.xml. In this example we configure some levels to be more silent and concentrate on the output of the camunda engine:

    <configuration>
      <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <!-- encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
        <encoder>
          <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
      </appender>
    
      <root level="debug">
        <appender-ref ref="STDOUT" />
      </root>
    
      <logger name="org.apache.ibatis" level="info" />
      <logger name="javax.activation" level="info" />
      <logger name="org.springframework" level="info" />
    
      <logger name="org.camunda" level="info" />
      <logger name="org.camunda.bpm.engine.test" level="debug" />
    </configuration>
    
  11. Run the JUnit test (right click on the testHappyPath method and select Run As > JUnit Test). You should get a green bar in the JUnit window. Can you see the output of your script task in the console?

  12. Have a look at the Camunda Platform Assert Library User Guide to get more information about the test library. Using the Camunda Platform Assert Library will become more important later on as we create more complex tests.

On this Page: