Environment (Required on creation):

Any

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

The Module "camunda-bpm-spring-boot-starter-test" uses "camunda-bpm-assert-assertj3-11-1". See https://github.com/camunda/camunda-bpm-spring-boot-starter/blob/master/starter-test/pom.xml. 

Using a new Spring Boot version (e.g. 2.5.6) typically an AssertJ version 3.21 ends up on the classpath. That leads to incompatibilities, see https://github.com/camunda/camunda-bpm-assert/issues/149, which quickly leads to broken builds and long hours searching for causes and fixes. Unless an AspectJ Version is set explicitly in the pom, but we tend to forget that. 

Steps to reproduce (Required on creation):

Use a new Spring Boot, do not set any assertj version explicitly and use this method in test: org.camunda.bpm.engine.test.assertions.bpmn.ProcessInstanceAssert#hasPassed

Observed Behavior (Required on creation):

org.camunda.bpm.engine.test.assertions.bpmn.ProcessInstanceAssert#hasPassed(java.lang.String...) causes Error, see  https://github.com/camunda/camunda-bpm-assert/issues/149

Expected behavior (Required on creation):

The default AspectJ Version coming from Spring Boot can be used, without explicit version crunching.

Root Cause (Required on prioritization):

Solution Ideas (Optional):

Would it be possible to consolidate this, so we do not need to set an AssertJ version explicitly, etc.?

Hints (optional):

See https://docs.camunda.org/manual/latest/user-guide/testing/#camunda-assertions. 

This issue is a litte feature and a little bug, feel free to adjust.