"Standalone In Memory Test Configuration" is using drop-create schemaUpdate, which cases errors in build output

Camunda 7 Topics Discussion & Questions
1

similar to: Instantiation fails when database schema update is set to "drop-create"

When running Springbook with @Rule public ProcessEngineRule processEngine = new StandaloneInMemoryTestConfiguration().rule(), the default usage is to have drop-create as the schema update.

What is the reason for this, as it causes non-blocking errors in the build:
such as

2019-04-04 13:14:18.959  INFO   --- [           main] .b.t.c.SpringBootTestContextBootstrapper : Using TestExecutionListeners: [org.springframework.test.context.web.ServletTestExecutionListener@55f616cf, org.springframework.test.context.support.DirtiesContextBeforeModesTestExecutionListener@1356d4d4, org.springframework.boot.test.mock.mockito.MockitoTestExecutionListener@c03cf28, org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener@1329eff, org.springframework.test.context.support.DirtiesContextTestExecutionListener@6497b078, org.springframework.test.context.transaction.TransactionalTestExecutionListener@41c2284a, org.springframework.test.context.jdbc.SqlScriptsTestExecutionListener@53aad5d5, org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener@46fa7c39, org.springframework.boot.test.autoconfigure.restdocs.RestDocsTestExecutionListener@1fb700ee, org.springframework.boot.test.autoconfigure.web.client.MockRestServiceServerResetTestExecutionListener@4f67eb2a, org.springframework.boot.test.autoconfigure.web.servlet.MockMvcPrintOnlyOnFailureTestExecutionListener@4a668b6e, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverTestExecutionListener@5f683daf]2019-04-04 13:14:23.747 ERROR   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03015 Problem during schema operation 'drop' with statement '-- 
-- 
-- 
-- 
-- 
alter table ACT_RE_DECISION_DEF 
drop constraint ACT_FK_DEC_REQ'. Cause: 'Table "ACT_RE_DECISION_DEF" not found; SQL statement:
-- 
-- 
-- 
-- 
-- 
alter table ACT_RE_DECISION_DEF 
drop constraint ACT_FK_DEC_REQ [42102-197]'
2019-04-04 13:14:23.752 ERROR   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03015 Problem during schema operation 'drop' with statement 'drop index ACT_IDX_DEC_DEF_TENANT_ID'. Cause: 'Index "ACT_IDX_DEC_DEF_TENANT_ID" not found; SQL statement:
drop index ACT_IDX_DEC_DEF_TENANT_ID [42112-197]'
2019-04-04 13:14:23.753 ERROR   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03015 Problem during schema operation 'drop' with statement 'drop index ACT_IDX_DEC_DEF_REQ_ID'. Cause: 'Index "ACT_IDX_DEC_DEF_REQ_ID" not found; SQL statement:
drop index ACT_IDX_DEC_DEF_REQ_ID [42112-197]'
2019-04-04 13:14:23.753 ERROR   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03015 Problem during schema operation 'drop' with statement 'drop index ACT_IDX_DEC_REQ_DEF_TENANT_ID'. Cause: 'Index "ACT_IDX_DEC_REQ_DEF_TENANT_ID" not found; SQL statement:
drop index ACT_IDX_DEC_REQ_DEF_TENANT_ID [42112-197]'
2019-04-04 13:14:23.754  INFO   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'drop' on component 'decision.engine' with resource 'org/camunda/bpm/engine/db/drop/activiti.h2.drop.decision.engine.sql'
2019-04-04 13:14:23.920  INFO   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'engine' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.engine.sql'
2019-04-04 13:14:23.982  INFO   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'history' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.history.sql'
2019-04-04 13:14:24.006  INFO   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'identity' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.identity.sql'
2019-04-04 13:14:24.025  INFO   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'case.engine' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.case.engine.sql'
2019-04-04 13:14:24.034  INFO   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'case.history' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.case.history.sql'
2019-04-04 13:14:24.039  INFO   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'decision.engine' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.decision.engine.sql'
2019-04-04 13:14:24.050  INFO   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03016 Performing database operation 'create' on component 'decision.history' with resource 'org/camunda/bpm/engine/db/create/activiti.h2.create.decision.history.sql'
2019-04-04 13:14:24.090  INFO   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03067 No history level property found in database
2019-04-04 13:14:24.091  INFO   --- [           main] org.camunda.bpm.engine.persistence       : ENGINE-03065 Creating historyLevel property in database for level: HistoryLevelFull(name=full, id=3)
2019-04-04 13:14:24.164  INFO   --- [           main] org.camunda.bpm.engine                   : ENGINE-00001 Process Engine default created.

@jangalinski even in the travis builds of the Camunda spring boot, I can see where this error appears in passing logs.

Whats the history on this?

THanks

2

Digging deeper, this seems to be a conflict related to using @SpringBootTest and the processenginerule.

If you just run Springboot with something like

@SpringBootTest(classes = CamundaVanillaEngineApplication,
                properties = ["camunda.bpm.job-execution.enabled=false"],
                webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT)

and have no ProcessEngineRUle, then there is none of the error above.

So based on this, and the usage of StandaloneInMemoryTestConfiguration in Camunda springboot.

It would seem that the docs miss a huge aspect of testing consideration?
https://docs.camunda.org/manual/latest/user-guide/spring-framework-integration/testing/

Where it only shows a variation of using ProcessEngineRule.
But given that a setup of the engine using springboot is likely spinning up other components in the application, what is the value of use ProcessEngineRule? you can still access all of the engine services with import static org.camunda.bpm.engine.test.assertions.ProcessEngineTests.*;

3

Hm, maybe that is why I never met this problem … for me its either “unit test” - use the processEngineRule to set up or “integration test” - use spring boot to set up … never did both …

4

@jangalinski can see this error appear is some of the spring boot Travis builds:

http://cdn.travis-ci.org/camunda/camunda-bpm-spring-boot-starter/builds/383611871

https://cdn.travis-ci.org/camunda/camunda-bpm-spring-boot-starter/builds/198547738

5

@jangalinski any ideas on a possible fix?

If i remove the processenginerule, we do not get auto engine registration.

6

@jangalinski my current workaround to this problem is something like this:

import io.digitalstate.camunda.coverage.bpmn.CoverageBuilder
import io.digitalstate.camunda.coverage.bpmn.SequenceFlowHistory
import org.camunda.bpm.engine.runtime.ProcessInstance
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.boot.test.context.SpringBootTest
import org.springframework.test.context.ActiveProfiles
import spock.lang.Shared
import spock.lang.Specification
import spock.lang.Stepwise

import java.util.logging.Logger

import static org.camunda.bpm.engine.test.assertions.bpmn.BpmnAwareAssertions.assertThat
import static org.camunda.bpm.engine.test.assertions.bpmn.BpmnAwareTests.*

@SpringBootTest(classes = CamundaVanillaEngineApplication,
       properties = ["camunda.bpm.job-execution.enabled=false",
                     "camunda.bpm.auto-deployment-enabled=false",
                     "camunda.bpm.metrics.enabled=false"],
       webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT) // To disable web apps and rest: WebEnvironment.NONE
@ActiveProfiles(["test"])
@Stepwise
class Test1Spec extends Specification implements CoverageBuilder, SequenceFlowHistory {
   @Shared
   Logger log = Logger.getLogger(getClass().getName())

   @Shared
   String deploymentId

   @Shared ProcessInstance processInstance

   // Recreates setupSpec() functionality.
   // Underscore is used to indicate a similar method of setupSpec() but a version that was run during autowire
   // setupSpec() does not work as it is running outside of the
   // spring TestContext (aka: no injection has occurred yet and thus the engine is not ready).
   // Known issue in Spock Spring Community.
   // Add Beans as method Params if they are needed
   @Autowired
   def _setupSpec() {
       def deployment = repositoryService().createDeployment()
               .addInputStream(getSequenceFlowFileName(), getSequenceFlowListenerScript())
               .addModelInstance('1.3User.bpmn', addSequenceFlowListeners('bpmn/1.3User.bpmn'))
               .name('1.3User-Test')
               .enableDuplicateFiltering(false)
               .deploy()
       deploymentId = deployment.getId()
   }


   def "test context loads"() {
       when: "Starting a instance of UserTasks3InRow"
       processInstance = runtimeService().startProcessInstanceByKey("UserTasks3InRow")

       then: "Process should be waiting at UT1"
       assertThat(processInstance).isWaitingAt("Task_0cy2app")
       coverageSnapshot(processInstance, 'UT1')

       then: "Have Johnny claim task Task_0cy2app"
       claim(task(), "Johnny")

       then: "Check that Johnny is the assignee of Task_0cy2app"
       assert task().assignee == "Johnny"

       then: "Complete Task_0cy2app"
       complete(task())

       then: "Process should be waiting at Task_00rw6t5"
       assertThat(processInstance).isWaitingAt("Task_00rw6t5")
       coverageSnapshot(processInstance, 'UT2')
   }

   def "stage 2 test"() {
       when: "There is a active process and Claim and Complete Task_00rw6t5"
       assertThat(processInstance).isActive()
       assertThat(processInstance).isWaitingAt("Task_00rw6t5")

       claim(task(), "Chris")
       complete(task())

       then: "Process should be waiting at Task_0z8g5sp"
       assertThat(processInstance).isWaitingAt("Task_0z8g5sp")
       coverageSnapshot(processInstance, 'UT3')

       then: "Complete Task_0z8g5sp without it being assigned"
       complete(task())

       then: "Process instance should have been completed"
       assertThat(processInstance).isEnded()
       coverageSnapshot(processInstance, 'Completion')
   }

   def cleanupSpec() {
       saveCoverageSnapshots()
       // Run snapshots before deployment deletion.
       // When a deployment is deleted, all data used by coverage is deleted.
       repositoryService().deleteDeployment(deploymentId,
               true,
               true,
               true)
//        println "Deployment ID: '${deploymentId}' has been deleted"
       log.info("see /target/bpmn-converage for coverage")
   }
}

The rule is just completely ignored

7