JUnit 5 Migration
1. Inspect the Current State
- Identify JUnit 3, JUnit 4, Jupiter, and Vintage usage.
- Identify runners, rules, categories, and old assertions.
- Read references/migration-map.md before rewriting test infrastructure.
- Read references/runners-rules-and-categories.md when legacy JUnit 4 infrastructure is non-trivial.
2. Migrate Incrementally
- Replace JUnit 4 imports with Jupiter imports in the smallest safe slice.
- Replace runners and rules with Jupiter extensions, lifecycle callbacks, or tags.
- Preserve observable behavior before cleaning style.
- Remove Vintage only when the migrated slice is stable.
- Keep migration and cleanup separate when both are large.
3. Validate the Migration
- Run the narrow slice first.
- Rerun the affected module or suite.
- Keep compatibility evidence visible if the migration changes behavior unexpectedly.
- Read references/migration-playbook.md when the suite is large or mixed-version.
4. Troubleshooting
- Problem: The repo still depends on JUnit 4 runners. Fix: Replace them with Jupiter extensions or platform-supported alternatives one slice at a time.
- Problem: The suite still needs Vintage. Fix: Limit Vintage to the remaining legacy area and keep the migration boundary explicit.
- Problem: The migration changed the lifecycle behavior unexpectedly. Fix: Compare setup and teardown scope, shared fixtures, and ordering assumptions before changing assertions.