Please provide an example on how to provide a custom configuration about camunda-bpm-junit5 HOT 12 CLOSED

When you setup your project with Maven, you put the application.yml into src/main/resources and the camunda.cfg.xml into src/test/resources. With this setup, all test classes and resources are not included in the deliverable artifact.

Also: The spring boot engine will ignore the camunda.cfg.xml at all. They could not interfere.

I will have a look into your suggestion.

from camunda-bpm-junit5.

Hi @criew and @Alex-Ph,

you can find an example to use a process engine that you you configure in your code here: https://github.com/camunda-community-hub/camunda-bpm-junit5/blob/use_own_process_engine/examples/engine-camunda-bpm-assert/src/test/java/org/camunda/bpm/unittest/engine/UseProcessEngineTest.java.

It's created on a new branch.

Does this example match your requirements?

from camunda-bpm-junit5.

Hi @Alex-Ph,

this extension starts a Camunda Engine with an In-Memory database without any container enviroment. The camunda.cgf.xml is the only way to configure the engine, so it is required.

Usually, the test engine has a different setup than the production-/development-engine.

from camunda-bpm-junit5.

Thinking about your suggestions, it could be possible with some internal refactoring to read the configuration from application.yml

But how to decide, which parameters are important for the unit test and which are not? For example, I don't want use the file based database for unit tests.

from camunda-bpm-junit5.

For my tests it would be enough to provide something like an inline camunda.cfg within a builder pattern or something similar, so I don't have to create an extra camunda config file.

I don't know what would happen, when I provide a camunda.cfg.xml and an application.yml in my project. Who will "win"? So I want to avoid defining this extra file. When writing "old" junit tests 4.0.3 you were able to define the StandaloneInMemoryTestConfiguration as a rule. Perhaps this config-class can be reused here somehow.

from camunda-bpm-junit5.

This is also an issue in our project. Basically camunda.cfg.xml is a Spring XML Configuration. Would be cool, if one could provide a Spring Configuration Class which is used to setup the engine instead.

from camunda-bpm-junit5.

Hi @Alex-Ph and @criew,

I've created an example to test a process automated with the Camunda-bpm-spring-boot-starter and JUnit 5 here: https://github.com/camunda-community-hub/camunda-bpm-junit5/tree/spring-boot-example/examples/example-spring-boot-testing. This extension is not required to run the tests. Instead, spring manages to use the engine configured with the spring boot mechanisms in the tests.

What do you think?

from camunda-bpm-junit5.

Hi @ingorichtsmeier,

We have several kinds of test in our project.

1. Test for Delegates mainly using Mockito - no engine, no spring context
2. Tests for Diagram flows using ProcessEngineRule/ProcessEngineExtension and Delegate Mocking (org.camunda.bpm.engine.test.mock.Mocks::register)
3. "Integration" - Tests using a full Spring Context (SpringBootTest)

Your solution is basically what we do for the "Integration Tests" (3), but cannot be used for Diagram Tests (2), because a full Spring Context will be set up which takes a lot of time. In addition, we need the ProcessEngineExtension features for selective Deployment.

The "problem" with ProcessEngineExtension for us is, that we need to create and reference several XML files (camunda.cfg.xml, another-camunda.cfx.xml, ...) which duplicate parts of our Spring configuration.

It would be very nice to have something like:

@RegisterExtension
 ProcessEngineExtension extension = ProcessEngineExtension.builder()
    .configurationResourceClass(MyProcessEngineConfiguration.class)
    .build();

where MyProcessEngineConfiguration extends ProcessEngineConfiguration.

The interesting parts are ProcessEngineExtension::114 and TestHelper::490.

protected void initializeProcessEngine() {
    processEngine = TestHelper.getProcessEngine(configurationResource);
    processEngineConfiguration = (ProcessEngineConfigurationImpl) processEngine.getProcessEngineConfiguration();
  }

public static ProcessEngine getProcessEngine(String configurationResource) {
    ProcessEngine processEngine = processEngines.get(configurationResource);
    if (processEngine==null) {
      LOG.debug("==== BUILDING PROCESS ENGINE ========================================================================");
      processEngine = ProcessEngineConfiguration
        .createProcessEngineConfigurationFromResource(configurationResource)
        .buildProcessEngine();
      LOG.debug("==== PROCESS ENGINE CREATED =========================================================================");
      processEngines.put(configurationResource, processEngine);
    }
    return processEngine;
  }

TestHelper (which is Camunda Distribution) could be changed to optionally take a Configuration not only a Configuration Resource.

Mmh, maybe we could overwrite initializeProcessEngine and do our own thing here ;-).

from camunda-bpm-junit5.

Hi @ingorichtsmeier,

I think that should work.

ProcessEngineExtension::getProcessEngineConfiguration will not return the correct value in your example, so maybe it is better to implement a method that takes a ProcessEngineConfiguration instead of ProcessEngine.

ProcessEngineConfiguration cfg = ...; ProcessEngineExtension extension = ProcessEngineExtension.builder().configuration(cfg).build();

In ProcessEngineExtension rewrite initializeProcessEngine to something like:

protected void initializeProcessEngine() {
    if (processEngineConfiguration != null) {
        processEngine = processEngineConfiguration.buildProcessEngine();
    }
    else {
       processEngine = TestHelper.getProcessEngine(configurationResource);
      processEngineConfiguration = (ProcessEngineConfigurationImpl) processEngine.getProcessEngineConfiguration();
    }
  }

Initialization is a little bit more complex so I'd do it in a "BaseTest" - would be really good if issue #6 is solved as well.

from camunda-bpm-junit5.

Hey @ingorichtsmeier,
This example looks good to me .

from camunda-bpm-junit5.

Hi @ingorichtsmeier

is there any progress on this issue? I would very much appreciate a version as well, where I don't have to use camunda.cfg.xml but can pass a custom ProcessEngine or ProcessEngineConfiguration instead.

Cheers,
Stefan

from camunda-bpm-junit5.

Hi @stefanzilske,

I've merged the open branch yesterday. The release of 1.1.0 should appear in maven central soon.

from camunda-bpm-junit5.