Spring style of initializing process test coverage rule fails to generate a class level report

[martinschimak]

Initialising the process test coverage rule for spring like this

  @Rule @ClassRule
  public static ProcessEngineRule rule;

  @PostConstruct
  void initRule() {
    rule = TestCoverageProcessEngineRuleBuilder.create(processEngine).build();
  }

fails to generate a process test coverage report on the "class level". It seems that it can't be produced because at the moment junit looks for an @ClassRule annotated rule, it is not yet initialised.

[lldata]

Unrelated, yet related:
Initially when I started looking at Spring enabling the test coverage plugin, I was investigating how to be able to write Camunda tests with Cucumber. As I remember it, it is impossible to make Cucumber work together with JUnit Rules.

So from a Spring perspective, getting rid of Rule/ClassRule (at least when used with Spring) would be the most desirable outcome of this bug.

[lldata]

I am afraid that the Spring patch I provided is incomplete / broken.

When this issue came up, I did a Spike to see if I could refactor the plugin to support Spring TestExecutionListeners. https://docs.spring.io/spring/docs/current/spring-framework-reference/html/integration-testing.html#__testexecutionlisteners

I didn't make any progress. To me the codebase was too tightly coupled to JUnit 4 Rules and it was hard to see why state was changed and when those calls were made. But code all around assumed that variables were in a certain state to do their work. So I failed to pull the refactoring off.

Now I just read about JUnit 5. In JUnit 5 Rules as deprecated and replaced by Extensions.
http://www.codeaffine.com/2016/04/06/replace-rules-in-junit5/

So if Camunda Test coverage should support JUnit 4, JUnit 5 and Spring testing, maybe it would be a good idea to decouple the code more from Rules? And then have adaptors for JUnit 4, 5 and TestExecutionListeners.

I suspect that JUnit 5 is flexible enough to cover the Spring support. At least Spring 5.0 support ..

[lldata]

At some point I'd like @falko 's feedback on my observations above ...

[falko]

Sounds reasonable. But I'm not the best to judge a refactoring like this, because I don't know the latest code so well.

[StephenOTT]

interested in using Cumcumber for camunda as well. anyone start any work on this?

[jangalinski]

we did an extension for jbehave a while ago. Seems better fitting for processes because of the "given-scenario" support. https://github.com/camunda/camunda-bpm-jbehave

[StephenOTT]

@jangalinski did you ever create a "simplified" implementation? The jbehave camunda implamation is (IMO) super complicated (while very advanced and option rich) with multiple levels of abstractions and configuration files. Its the SpaceShip model when typically we need a Toyota camry

[martinschimak]

Hi all. I added a quick (and a bit dirty) example of how to leverage the camunda assert "scenario" runner in combination with cucumber to an example/cucumber branch. I can execute it within intellij but did not yet take care of more. You find the feature file here https://github.com/camunda/camunda-bpm-assert-scenario/blob/example/cucumber/example/src/test/resources/org/camunda/bpm/scenario/examples/paymentretrieval/RestoreCredit.feature and three related files in the package. I think what's interesting is that the test becomes truly behavioural, there is no hard dependency to the way how a requirement is implemented in the process. Some feedback would be awesome ofc. :-)