# Unit Testing CaseMigration

**URL:** <https://forum.flowable.org/t/unit-testing-casemigration/9219>\
**Category:** Flowable Engine\
**Created:** [April 19, 2022, 7:50pm UTC](https://forum.flowable.org/t/unit-testing-casemigration/9219 "2022-04-19T19:50:05Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dandoucet](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@Dandoucet](https://forum.flowable.org/u/Dandoucet)\
**Post date:** [April 19, 2022, 7:50pm UTC](https://forum.flowable.org/t/unit-testing-casemigration/9219/1 "2022-04-19T19:50:05Z")

</div>

Hi,

I’m trying to implement a case migration and I’m starting to write some unit tests so that I can confirm the end result is what I’m expecting.

I’ve used the migration unit tests from [here](https://github.com/flowable/flowable-engine/tree/main/modules/flowable-cmmn-engine/src/test/java/org/flowable/cmmn/test/migration) as a starting point. These tests work since they are relatively simple unit tests, however, the cmmn model I’m working with includes a Process Task and when executing the test I’m getting the following error

`org.flowable.common.engine.api.FlowableException: Could not start process instance: no interface org.flowable.cmmn.engine.impl.process.ProcessInstanceService implementation found`

Currently I’m using the same [flowable.cmmn.cfg.xml](https://github.com/flowable/flowable-engine/blob/main/modules/flowable-cmmn-engine/src/test/resources/flowable.cmmn.cfg.xml) from your tests minus the test delegate beans and although I’ve tried a few different approaches in the cfg file to get the processInstanceService instantiated I’ve yet to have any success.

Is there any direction you can provide or links to a sample? I looked through all the cmmn test cases thinking there must be one for a model that includes a process task but couldn’t find any.

Thanks,  
Dan

---

<div class="post-metadata">

**Author:** ![joram](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/joram/32/26_2.png) [@joram](https://forum.flowable.org/u/joram)\
**Post date:** [April 20, 2022, 7:07pm UTC](https://forum.flowable.org/t/unit-testing-casemigration/9219/2 "2022-04-20T19:07:29Z")

</div>

Is it possible to share the CMMN xml’s in question and the code you are using to test with? That way we can reproduce.

Looking at the exception: do you have the flowable-cmmn-engine-configurator dependency on your classpath (as that’s where the default implementation of ProcessInstanceService is in)?

---

<div class="post-metadata">

**Author:** ![Dandoucet](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@Dandoucet](https://forum.flowable.org/u/Dandoucet)\
**Post date:** [April 20, 2022, 8:19pm UTC](https://forum.flowable.org/t/unit-testing-casemigration/9219/3 "2022-04-20T20:19:16Z")

</div>

Hi,

I’ll create a representative sample of the CMMN xml and share that along with some sample code when I get a chance.

We were able to get past the ProcessInstanceService issue and a few follow on issues by including a processEngine configuration in the flowable.cmmn.cfg.xml and then adding it to the cmmn engine’s configurator property. Here’s more or less what the working config looks like. In order for it to work we also had to include an idGenerator

```auto
<?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="dataSource" class="org.flowable.common.engine.impl.test.ClosingDataSource">
        <constructor-arg>
            <bean class="com.zaxxer.hikari.HikariDataSource" destroy-method="close">
                <constructor-arg>
                    <bean class="com.zaxxer.hikari.HikariConfig">
                        <property name="minimumIdle" value="0" />
                        <!-- <property name="jdbcUrl" value="${jdbc.url:jdbc:h2:mem:flowable;DB_CLOSE_DELAY=1000}" /> -->
                        <property name="jdbcUrl" value="${jdbc.url:jdbc:h2:~/flowable-db/db6;AUTO_SERVER=TRUE;AUTO_SERVER_PORT=9091;DB_CLOSE_DELAY=-1}" />
                        <property name="driverClassName" value="${jdbc.driver:org.h2.Driver}" />
                        <property name="username" value="${jdbc.username:flowable}" />
                        <property name="password" value="${jdbc.password:flowable}" />
                    </bean>
                </constructor-arg>
            </bean>
        </constructor-arg>
    </bean>
    
  <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource" />
  </bean> 

    <bean id="cmmnEngineConfiguration" class="org.flowable.cmmn.engine.impl.cfg.StandaloneInMemCmmnEngineConfiguration">

        <property name="dataSource" ref="dataSource"/>

        <property name="engineLifecycleListeners">
            <list>
                <ref bean="dataSource"/>
            </list>
        </property>
        <property name="databaseSchemaUpdate" value="true" />
       <!-- <property name="transactionManager" ref="transactionManager" />-->
        <property name="asyncExecutorActivate" value="false" />
        <property name="asyncExecutorDefaultAsyncJobAcquireWaitTime" value="1000" />
        <property name="asyncExecutorDefaultTimerJobAcquireWaitTime" value="1000" />

        <property name="asyncFailedJobWaitTime" value="1" />

        <property name="enableEntityLinks" value="true" />
        <!-- <property name="enableCaseDefinitionHistoryLevel" value="true" /> -->

        <property name="enableHistoricTaskLogging" value="true" />

        <property name="mailServerPort" value="5025" />    
        
        
         <property name="processInstanceService" >
           <ref bean="defaultProcessInstanceService" />        
        </property> 
          <property name="configurators">
            <list>
                <bean class="org.flowable.engine.configurator.ProcessEngineConfigurator">
                    <property name="processEngineConfiguration" ref="processEngineConfiguration" />
                </bean>               
            </list>
        </property>
 
 
    </bean>    
   
     <bean id="defaultProcessInstanceService" class="org.flowable.cmmn.engine.configurator.impl.process.DefaultProcessInstanceService">
        <constructor-arg ref="processEngineConfiguration"/> 
    </bean>

  
    <bean id="processEngineConfiguration" class="org.flowable.engine.impl.cfg.StandaloneProcessEngineConfiguration">
        <property name="jdbcUrl" value="${jdbc.url:jdbc:h2:~/flowable-db/db6;AUTO_SERVER=TRUE;AUTO_SERVER_PORT=9091;DB_CLOSE_DELAY=-1}" />
        <property name="jdbcDriver" value="${jdbc.driver:org.h2.Driver}" />
        <property name="jdbcUsername" value="${jdbc.username:flowable}" />
        <property name="jdbcPassword" value="${jdbc.password:flowable}" />
        <property name="databaseSchemaUpdate" value="true" />
        
        <property name="asyncExecutorActivate" value="false" />
        <property name="asyncExecutorDefaultAsyncJobAcquireWaitTime" value="1000" />
        <property name="asyncExecutorDefaultTimerJobAcquireWaitTime" value="1000" />
        
        <property name="asyncFailedJobWaitTime" value="1" />
        
        <property name="enableEntityLinks" value="true" />
        <property name="enableProcessDefinitionInfoCache" value="true" />  
        <property name="idGenerator">
			<bean class="org.flowable.common.engine.impl.persistence.StrongUuidGenerator" />
		</property>  
		
		 
      
    </bean>

    
</beans>

```

We did, however, run into other issues with this approach as it wasn’t autowiring our delegates. We had to remove the @FlowableCmmnTest annotation from the AbstractCaseMigrationTest and replaced with:

```auto
@SpringBootTest(classes = OurApplication.class )
@ActiveProfiles("development")

```

This negated the whole use of the flowable.cmmn.cfg.xml file and used the engine config in our app instead and allowed us to Autowire our delegates. We’re now having some issues with the actual migration but I’ll post that separately.