Skip to content

Add mockito-junit-jupiter dependency when MockitoExtension is introduced#941

Merged
timtebeek merged 2 commits intomainfrom
bmuschko/mockito-ext-dep
Mar 24, 2026
Merged

Add mockito-junit-jupiter dependency when MockitoExtension is introduced#941
timtebeek merged 2 commits intomainfrom
bmuschko/mockito-ext-dep

Conversation

@bmuschko
Copy link
Copy Markdown
Contributor

@bmuschko bmuschko commented Mar 24, 2026

Summary

  • Mockito1to3Migration adds @ExtendWith(MockitoExtension.class) to JUnit 5 tests using Mockito annotations (@Mock, @Spy, @Captor, @InjectMocks), but does not add the org.mockito:mockito-junit-jupiter dependency that provides MockitoExtension. This causes compilation failures post-migration when the dependency isn't already on the classpath.
  • Adds a new AddMockitoJupiterDependency ScanningRecipe that detects the same preconditions (Mockito annotations + JUnit 5 types + no existing @ExtendWith(MockitoExtension.class)) and adds mockito-junit-jupiter as a test-scoped dependency.
  • Wired into Mockito1to3Migration immediately after AddMockitoExtensionIfAnnotationsUsed. The Mockito1to4Migration and Mockito1to5Migration chains inherit this and their UpgradeDependencyVersion steps upgrade the version accordingly.

Why not a declarative YAML recipe?

A declarative AddDependency with onlyIfUsing: org.mockito.junit.jupiter.MockitoExtension was not viable. Within a YAML recipe list cycle, all ScanningRecipe scan phases run before all edit phases. The AddDependency scan would check for MockitoExtension usage before AddMockitoExtensionIfAnnotationsUsed has added @ExtendWith(MockitoExtension.class), so the type is never found and the dependency is never added. An imperative ScanningRecipe with a custom scanner that checks the original source preconditions solves this.

…n.class) is introduced

The Mockito1to3Migration recipe adds @ExtendWith(MockitoExtension.class) to
JUnit 5 tests using Mockito annotations, but does not add the
org.mockito:mockito-junit-jupiter dependency that provides MockitoExtension.
This causes compilation failures when the dependency is not already on the
classpath.

Add a new ScanningRecipe (AddMockitoJupiterDependency) that detects the same
preconditions and adds the dependency as a test-scoped artifact.

A declarative YAML recipe using AddDependency with onlyIfUsing was not viable
because within a recipe list cycle all scan phases run before all edit phases.
The AddDependency scan would check for MockitoExtension usage before
AddMockitoExtensionIfAnnotationsUsed has added it, so the type is never found.
@bmuschko bmuschko force-pushed the bmuschko/mockito-ext-dep branch from 5df6b31 to 8e681af Compare March 24, 2026 22:04

@Override
public AtomicBoolean getInitialValue(ExecutionContext ctx) {
return new AtomicBoolean(false);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An AtomicBoolean Accumulator always makes me doubt we correctly handle multi module projects. Can we make this a mapping from JavaProject marker to a Boolean instead?

@bmuschko bmuschko added the bug Something isn't working label Mar 24, 2026
Replace AtomicBoolean with a Map<JavaProject, Boolean> accumulator so
the dependency is only added to modules that actually need it in
multi-module projects.
@github-project-automation github-project-automation bot moved this from In Progress to Ready to Review in OpenRewrite Mar 24, 2026
@timtebeek timtebeek merged commit fc88d78 into main Mar 24, 2026
1 check passed
@timtebeek timtebeek deleted the bmuschko/mockito-ext-dep branch March 24, 2026 22:35
@github-project-automation github-project-automation bot moved this from Ready to Review to Done in OpenRewrite Mar 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

2 participants