Cucumber JVM 7.x step definition compatibility with JUnit 5 test runner

Answer to the Core Questions

1. Under what conditions does --dry‑run confirm cross‑version step‑definition validity?

The dry‑run flag only verifies that the glue package is on the test classpath, that Cucumber can instantiate the step‑definition classes, and that no runtime errors such as NoSuchMethodError or IncompatibleClassChangeError are thrown during the initialization phase. If any of those conditions fail, --dry‑run aborts with an initialization error before reporting the number of scenarios.

Thus a clean dry‑run indicates that the step‑definitions are syntactically correct and compatible with the *current* Cucumber JVM version, but it does not guarantee that the same classpath will be used at test execution time.

2. Does cucumber.yml profile reversion reliably restore functionality after a JVM major upgrade?

Reverting the cucumber.yml profile only restores functionality if the project is rebuilt against the exact dependencies that were used with the older Cucumber JVM (e.g., 6.x). A simple profile switch without a mvn clean (or gradle clean) may leave bytecode compiled against 7.x on the classpath, leading to NoSuchMethodError or method‑signature mismatches at runtime.

Therefore, after changing the profile you should run a full clean rebuild and verify that the dependency tree contains the intended Cucumber core version before executing tests.

3. How do JUnit 5 versus TestNG runtime differences influence detection of glue‑code breakage?

With JUnit 5’s platform engine, Cucumber delays test discovery until the execution phase. Glue‑code errors (e.g., missing constructors or incompatible annotations) surface only when a scenario is actually run, so a suite may start cleanly and fail later during execution.

TestNG, on the other hand, initializes its listeners eagerly during suite startup. Glue‑code problems are therefore reported earlier—often at the beginning of the test run—before any scenarios are executed.

Both runners report undefined steps in the same way once the step matcher is active; the difference lies in the timing and visibility of the initialization failures.

Practical Steps for Your Scenario

1. Verify the classpath: run mvn dependency:tree -Dincludes=cucumber (or the Gradle equivalent) to ensure only one cucumber-core version is present, matching the one you expect to use.

2. Run a dry‑run with a clean build:

   mvn clean test -Dcucumber.dry-run=true
   

   Verify that the output ends with 0 scenarios and that no initialization errors appear.

3. If the dry‑run passes but runtime fails, check the exact exception thrown during test execution. Common culprits are NoSuchMethodError or ClassNotFoundException caused by stale 7.x bytecode.

4. When reverting a cucumber.yml profile, perform a full clean rebuild:

   mvn clean test -Dcucumber.profile=oldProfile
   

   Then confirm that the dependency tree still points to the older Cucumber core.

5. Compare runner behavior: execute the suite with JUnit 5 and then with TestNG (using cucumber-testng) and note when any initialization failures are reported.

What We Still Need to Know

Could you share the exact error message or stack trace that appears when the step definitions fail to load at runtime? That detail will help pinpoint whether the problem is a classpath mismatch, a 7.x bytecode issue, or something else.