Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-9452

Testing Spring Boot Applications: Support application context caching

XMLWordPrintable

      Scenario:

      • I use the Camunda Spring Boot Starter with @EnableProcessApplication to use processes.xml for deployment
      • I write a test as follows
      package my.package;
      
      import org.camunda.bpm.engine.RuntimeService;
      import org.junit.Test;
      import org.junit.runner.RunWith;
      import org.springframework.beans.factory.annotation.Autowired;
      import org.springframework.boot.test.context.SpringBootTest;
      import org.springframework.test.context.ActiveProfiles;
      import org.springframework.test.context.junit4.SpringRunner;
      import static org.assertj.core.api.Assertions.assertThat;
      
      @RunWith(SpringRunner.class)
      @SpringBootTest
      @ActiveProfiles("test")
      public class MyTest {
      
          @Autowired
          private RuntimeService runtimeService;
      
          @Test
          public void test() {
              // do 
              runtimeService....;
          }
      }
      

      Desired behavior:

      • Spring's test runner caches application context's by default grouped by test configuration. Under the assumption that a test has no side-effects (read: does not modify the application context or any embedded resources), the context can be safely reused in another test if the test has the exact same configuration. This speeds up test runtime.

      Current behavior:

      • When using context caching and there is more than one application context (e.g. because we have tests that use two different configurations; however the process engine configuration is the same), then the creation of the second context fails
      • The problem is that we then have two process engines with the same name at the same time. The second SpringBootProcessApplication bean tries to register its engine with the MBean container and an exception is raised.
      • In consequence, users must avoid to have multiple engines with the same name (e.g. by avoiding that there are two application contexts at the same time via @DirtiesContext or by ensuring unique engine names (which does not work well with processes.xml))

        This is the controller panel for Smart Panels app

              Unassigned Unassigned
              thorben.lindhauer Thorben Lindhauer
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: