Add JUnit 4 to JUnit 5 migration precondition recipe

[amishra-u]

Implement a scanning recipe that identifies and marks JUnit 4 test classes eligible for migration to JUnit 5. This precondition recipe analyzes test classes to determine migratability based on:

• Detection of supported vs. unsupported JUnit 4 rules and runners
• Analysis of class inheritance hierarchies to ensure parent and child test classes use only supported features
• Identification of @parameters annotations with class-type source attributes that cannot be migrated
• Validation that all ancestors in the class hierarchy are also migratable

The recipe marks only those test classes that can be successfully migrated, preventing build or test failures post-migration. This ensures fully automated, safe migrations by excluding classes with unsupported features from the migration process.

This precondition recipe is designed to work with declarative JUnit 4 to JUnit 5 migration recipes, ensuring the migration recipe only modifies classes that are guaranteed to migrate successfully.

Note: This recipe has been successfully used at Uber for large-scale JUnit 4 to JUnit 5 migrations. Upstreaming to benefit the broader OpenRewrite community.

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

🤖 Generated with Claude Code

[timtebeek]

Thanks for showcasing what you've done here @amishra-u ; Good to see how you're using this scanning precondition to limit results just to the whitelisted cases you know you can handle. Could be helpful for others looking to gradually adopt JUnit Jupiter still, with known cases not yet converted.

[amishra-u]

@timtebeek if everything looks good can you please merge it.

[timtebeek]

I had some reservations about knownMigratableClasses, especially since that looks at a first glance to be a required field that ties the recipe/precondition strongly to a particular set of classes only expected to be present in a small set of (potentially large!) projects. By comparison the other options all more broadly applicable, but this one as a required options strongly limits where and how the precondition can be applied; would you agree there? Is there a way to put this particular requirement in a separate precondition that you'll maintain yourself? Or even use an existing recipe for that requirement?

[amishra-u]

At Uber, we had many complex base test classes (around 10–20). Supporting all of their special cases via new or extended recipes was not practical, so we manually created JUnit 5 equivalents and added recipe to replace references of the original base classes.

These base classes contain shared test logic and are widely extended across the codebase. While micro-repos typically may include only one or two such classes, our monorepo grew into the double digits.

This option can be left empty and is therefore marked @nullable. Its values are inherently project-specific, so there is no sensible default for the open-source version of the recipe.

This recipe option worked well for us and could benefit others, but I’m happy to remove this option if it’s not a good fit for open source version.