[junit5] Possibility to provide a programatic process engine config instead of xml config

[arolfes]

Hi all,

I don't want to have a camunda.cfg.xml to use the JUnit 5 Extension. But without it will not work.

currently the ProcessEngineCoverageExtension class is final (Default for all kotlin classes). Therefore I don't have the possibility to override the org.camunda.bpm.extension.junit5.test.ProcessEngineExtension#initializeProcessEngine method.

From my point of view there are 3 possibilities to resolves this problem:

1. copy the code from the extension in your project and change the behavior. I don't like this approach at all...
2. make the class open

open class ProcessEngineCoverageExtension(

3. a method in the builder to add a standaloneProcessEngineConfig

class ProcessEngineCoverageExtension(
.
.
.
        /**
         * a standaloneProcessEngineConfiguration for initializing the processEngine,
         * when you don't want to use XML
         */
        private val standaloneProcessEngineConfiguration: StandaloneProcessEngineConfiguration? = null

        ) : ProcessEngineExtension(), BeforeAllCallback, AfterAllCallback {

    private var processEngineInitialized: ProcessEngine? = null

.
.
.
    override fun initializeProcessEngine() {
        if (standaloneProcessEngineConfiguration != null) {
            if (processEngineInitialized == null) {
                processEngineInitialized = standaloneProcessEngineConfiguration.buildProcessEngine()
            }
            processEngine = processEngineInitialized
            processEngineConfiguration = standaloneProcessEngineConfiguration
        } else {
            super.initializeProcessEngine()
        }
    }

    data class Builder(
            var configurationResource: String? = null,
            var standaloneProcessEngineConfiguration: StandaloneProcessEngineConfiguration? = null,
.
.
.
        /**
         * Sets the processEngineConfiguration and initializes the process engine with it
         */
        fun standaloneProcessEngineConfiguration(standaloneProcessEngineConfiguration: StandaloneProcessEngineConfiguration) = this.apply { this.standaloneProcessEngineConfiguration = standaloneProcessEngineConfiguration}
.
.
.
    }

}

What do you think? should I provide an PullRequest for second solution or the third one?

The third solution is currently blocked by #122

Or is there another way how to init the processEngine without xml config?

[zambrovski]

Hi,

Thank you for reporting. Why is the third solution blocked?

Cheers,

Simon

[arolfes]

Hi @zambrovski ,

thanks for the fast reply. It is blocked by issue number 122 Problem with RegisterExtension #122

I found a workaround for this problem. i will post it there

[arolfes]

With the workaround from issue #122 I can provide a pullRequest for the third solution if you like. It will also contains an example how to use it :-)

[rohwerj]

I prefer the third solution. But we would need to decide what takes precedence, if configuration source and engine configuration are both set.
Maybe we should provide distinct creation functions for the builder.
I created a PR for this #124 for discussion.
Please note that the process engine configuration has to be initialized for process test coverage.
Two configurations are provided for this:
ProcessCoverageInMemProcessEngineConfiguration and SpringProcessWithCoverageEngineConfiguration
Otherwise the configuration has to be initialized by calling ProcessCoverageConfigurator.initializeProcessCoverageExtensions(this);

[arolfes]

Hi @rohwerj ,

In my opion the code should throw an exception (like IllegalArgumentException or something like this). Why? Because this can only happen when the Developer configures both (XML and JavaConfig).

[zambrovski]

I would vote for creating logging a warning saying that both configurations were present and one of them was ignored. Throwing exception is too hard, and there might be scenarios, in that you can't prevent of having too configurations, but it might be ok to ignore one of this.

[arolfes]

fine for me,
ignore the java config if it is ok for you

[zambrovski]

@rohwerj What do you think? Do you want to provide a patch for it?
If this is done, we can try to release a version patching it...

[arolfes]

and i have one more request:

can you provide a working kotlin example in the readme?

What I figured out, I have to wrap the extension inside a companion object

@Deployment(resources = ["order-process.bpmn"])
internal class OrderProcessTest {

    companion object {

        @JvmStatic
        val configuration = StandaloneInMemProcessEngineConfiguration().apply {
            jdbcUrl = "jdbc:h2:mem:camunda;DB_CLOSE_DELAY=1000"
            jdbcDriver = "org.h2.Driver"
            jdbcUsername = "sa"
            jdbcPassword = ""
            databaseSchemaUpdate = ProcessEngineConfiguration.DB_SCHEMA_UPDATE_TRUE
            isJobExecutorActivate = false
            history = ProcessEngineConfiguration.HISTORY_FULL
            ProcessCoverageConfigurator.initializeProcessCoverageExtensions(this)
        }


        @JvmField
        @RegisterExtension
        val extension =
            ProcessEngineCoverageExtension.builder(processEngineConfiguration = configuration)
                .build()
    }
.
.
.

[rohwerj]

OK. Will provide a patch for logging a warning.
I would acutally like to get rid of the possibility to set both ways.
That's the reason for the specialized methods for creating the builder.
I deprecated the method of setting the configuration resource on the builder.
But I will integrate a logging there, if the builder was created using a java config and then actually ignore the configuration resource.
@arolfes I will also include the example for Kotlin

[arolfes]

Thank you @rohwerj for the improvement.

When do you @zambrovski plan the next release? 1.0.1?