@deployment does it really deploy a process definition ?

[heymjo]

Hi,

I have this simple test which fails because the process definition is not getting deployed.

@Test
@ContextConfiguration
public class DemoProcessTest extends AbstractTestNGSpringContextTests {

    @Autowired
    private RepositoryService repositoryService;

    @Deployment(resources = {"workflow/demo.bpmn20.xml"})
    public void simpleTest() {
        ProcessDefinition financialReport = repositoryService.createProcessDefinitionQuery()
                .processDefinitionKey("financialReport").latestVersion().singleResult();
        Assert.assertNotNull(financialReport);
    }
}

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I can get it to work by putting the deploymentResources attribute of SpringProcessEngineConfiguration, but i thought it would be nicer with the annotation. I also checked act_re_deployment table and indeed it is empty.

Also, @Deployment claims to create *and* delete a deployment around a test method' in the javadoc. When it deletes the deployment will it do a cascade delete ?

Thanks
Jorg

[frederikherema1]

Hi,

All our internal QA used the @Deployment annotation, so it works allright. If you look at the spring-chapter in the userguide, it says you have to use the ActivitiRule, this will scan the test for deployment annotations and do it's magic. Just running a vanilla spring-test won't: http://activiti.org/userguide/index.html#springUnitTest

It cascades, yes. The ActivitiRule javadocs clearly state this:

* <p>You can declare a deployment with the {@link Deployment} annotation.
* This base class will make sure that this deployment gets deployed before the
* setUp and {@link RepositoryService#deleteDeployment(String, boolean) cascade deleted}
* after the tearDown.
* </p>


[heymjo]

ah so that's what the ActivitiRule is, i always thought it was a drools thingy.

Anyways i'm using TestNG, this rule stuff looks quite junit specific. Am i out of luck here ?

[frederikherema1]

Nope, you can always create a custom base-test class in NG that behaves the same on setup/teardown (or whatever it is called inTestNG ):


deploymentId = TestHelper.annotationDeploymentSetUp(processEngine, method.getMethod().getDeclaringClass(), method.getName());

// … and later…

TestHelper.annotationDeploymentTearDown(processEngine, deploymentId, method.getMethod().getDeclaringClass(), method.getName());


[heymjo]

OK with testng it looks like this then:


@Test
@ContextConfiguration
public class DemoProcessTest extends AbstractTestNGSpringContextTests {

    @Autowired
    private ProcessEngine processEngine;

    @Autowired
    private RepositoryService repositoryService;

    private ThreadLocal<String> deploymentId = new ThreadLocal<String>();

    @BeforeMethod
    public void setup(java.lang.reflect.Method method) {
        String id = TestHelper.annotationDeploymentSetUp(processEngine, method.getDeclaringClass(), method.getName());
        this.deploymentId.set(id);
    }

    @AfterMethod
    public void tearDown(java.lang.reflect.Method method) {
        TestHelper.annotationDeploymentTearDown(processEngine, this.deploymentId.get(), method
                .getDeclaringClass(), method.getName());
        this.deploymentId.remove();
    }

    @Deployment(resources = {"workflow/demo.bpmn20.xml"})
    public void simpleTest() {
        ProcessDefinition financialReport = repositoryService.createProcessDefinitionQuery()
                .processDefinitionKey("financialReport").latestVersion().singleResult();
        Assert.assertNotNull(financialReport);
    }
}

it might be possible to use a testlistener as well which i guess are similar to your rules. But then you'll have to see how to initialize the process engine there, i figured it was nicer to just reuse the instance as initialized by the test. I put the deployment id as a threadlocal to allow testng parallel test execution (untested). AFAICT the ActivitiRule does not allow this but can ofcourse be easily modified.

HTH
Jorg

[frederikherema1]

Thanks for sharing