Feature Request > Add support for JUnit 5

[ghilainm]

Would be nice to add a JUnit 5 extension

[falko]

Would you like to give it try and maybe contribute something in this area?

[mutsys]

I would also like to be able to use this with JUnit 5. I took a look at the implementation of the existing JUnit 4 rule but to tell you the truth, it was very difficult to understand how this feature fits into the JUnit test lifecycle by reading the code. @falko, if you wouldn't mind putting together a short outline to help me out here, I might be able to bang this out in short order.

Also, have you given any thought to implementing this as a Spring Test TestExecutionListener? That way it would work with both JUnit 4 and 5..

[jangalinski]

What is the overall position of camunda regarding junit5? Does regular process testing work with junit5/ProcessEngineRule? Shouldn't that be solved first ... a camunda-junit5 test package before the support is implemented in depending test-libs?

[ov7a]

It seems like that TestCoverageProcessEngineRule is hard-wired to ProcessEngineRule, which in turn is hard-wired to JUnit4. I think this breaks SRP and OCP, and a good refactoring is required to separate ProcessEnglineRule from JUnit4 and make an adapter to JUnit5. Same goes for TestCoverageProcessEngineRule.

One can simply write a wrapper/adapter from Rule to Extension, but it would still depend on JUnit4.

@falko @NPDeehan Do you know what's the current state with JUnit5 in the main repository?

I've seen a bunch of closed tickets about migration to JUnit5 in Jira, but I haven't found anything related to ProcessEngineRule in release branches. There is an WIP branch test-junit5 from @yanavasileva, but it looks far from over. There is also a poll about Junit5 on Camunda forum by @NPDeehan, but there are only 17 votes :/

There is also a repo https://github.com/ybroeker/camunda-junit5, but I haven't tested it yet.

[falko]

I'm not aware of any coordinated effort to update to JUnit 5. I'm not sure how useful it would be to just use the process test coverage with JUnit 5 if you don't also have the engine bootstrapping and assertions available. So maybe this feature request should be raised against Camunda BPM first.

[yanavasileva]

The mentioned branch (WIP branch test-junit5) was a slack time project to explore the options, unfortunately, I didn't have time to continue the work on it.

As further information from the platform side, the following ticket has been created: https://jira.camunda.com/browse/CAM-11955 We haven't started the work on it, please let me know in case you are interested in making a contribution.

[mutsys]

I have time to devote to this and would be happy to contribute my efforts.

Mike

On Mon, Aug 3, 2020 at 11:53 PM yanavasileva notifications@github.com wrote:

The mentioned branch (WIP branch test-junit5 https://github.com/camunda/camunda-bpm-platform/commits/test-junit5) was a slack time project to explore the options, unfortunately, I didn't have time to continue the work on it.

As further information from the platform side, the following ticket has been created: https://jira.camunda.com/browse/CAM-11955 We haven't started the work on it, please let me know in case you are interested in making a contribution.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/camunda/camunda-bpm-process-test-coverage/issues/45#issuecomment-668415215, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACASZKEYKUVTMI2MVQWONUTR66V5ZANCNFSM4HU5JYOQ .

[jangalinski]

I would really like to use junit5 ... idea/wish: could this be a stand alone extension "camunda-test-junit5"? I suppose the core is not limited to the test-coverage extension and it would allow us to use junit5 arbitrary from this extension. wdyt?

[zambrovski]

This will be solved in a separate junit5 module, as described in #77

[DGilmour5]

Just a voice from a newbie. I'm doing a Camunda POC and testing is a big ask by my development management. I'm not too keen on getting going with jUnit4 when jUnit5 is coming out. I'm testing with this extension https://camunda.com/blog/2021/01/test-your-processes-with-junit-5/ and so far so good. So I too vote for jUnit5 support.

[madmax25]

What is the overall position of camunda regarding junit5? Does regular process testing work with junit5/ProcessEngineRule? Shouldn't that be solved first ... a camunda-junit5 test package before the support is implemented in depending test-libs?

@jangalinski Use as an extension would be ideal such as an @ExtendWith(CoverageProcessEngineExtension.class) @zambrovski I will look for this separate module

Currently the ProcessEngineExtension.class is located in separate git repo camunda-bpm-junit5.

It may make sense for camunda-bpm-process-test-coverage to consume and extend this for JUnit5 support??

[ingorichtsmeier]

Hey everybody,

I thought about a possible approach how to solve this issue with the exisiting camunda-bpm-junit5 extension.

One option is to duplicate the code the junit5 extension to keep the dependencies in your process-automation project clean. I don't think that you will write plain junit tests for processes, once you've seen the graphical test coverage.

Another option is to add a dependency to camunda-bpm-junit5 in this project and extend the ProcessEngineExtension class to provide access to the coverage methods.

In this branch: https://github.com/camunda-community-hub/camunda-bpm-junit5/tree/use_own_process_engine I opened the builder of the extension to use a given processEngine in the tests like:

@RegisterExtension
ProcessEngineExtension extension = ProcessEngineExtension
    .builder()
    .useProcessEngine(
         ProcessTestCoverageConfiguration.buildEngine())
    .build();

My branch didn't work right now and on a first glance it seems that the configuration of the test coverage is mixed up with the JUnit4 Rule, so not easily resusable.

What would be the biggerst benefit to the users? Merge the junit5 extension into the testcoverage, that every body who wants to use junit5 get testcoverage for free? Keep them seperated to follow different approaches in their repositories?