Add @MockitoSettings(strictness = Strictness.WARN) for Mockito migration#966
Draft
Add @MockitoSettings(strictness = Strictness.WARN) for Mockito migration#966
Conversation
…o migration Addresses the UnnecessaryStubbingException issue that occurs after migrating from Mockito 1.x, where unused stubbings were silently ignored but now fail under MockitoExtension's default STRICT_STUBS strictness. Two changes: 1. MockitoJUnitToMockitoExtension now adds @MockitoSettings even when @ExtendWith(MockitoExtension.class) is already present, preserving the original WARN strictness from the MockitoRule being removed. 2. New AddMockitoSettingsWithWarnStrictness recipe targets classes that already have @ExtendWith(MockitoExtension.class) but no MockitoRule to convert and no @MockitoSettings — the gap not covered by the existing recipe.
timtebeek
reviewed
Apr 8, 2026
| - org.openrewrite.java.testing.mockito.ReplacePowerMockito | ||
| - org.openrewrite.java.testing.junit5.MockitoJUnitToMockitoExtension | ||
| - org.openrewrite.java.testing.mockito.AddMockitoExtensionIfAnnotationsUsed | ||
| - org.openrewrite.java.testing.mockito.AddMockitoSettingsWithWarnStrictness |
Member
There was a problem hiding this comment.
I think we'd want to guard this with a precondition to only apply when the module has a dependency on a pre-version-3 of Mockito right?
What I'm trying to avoid is that folks who never used Mockito 1, 2 or 3, but say started at 4, then run our recipe to upgrade to 5, and suddenly see MockitoSettings restore an old default they had never used to begin with, reducing the strictness of their Mockito usage.
Would you agree with the above scenario & assessment?
Contributor
Author
There was a problem hiding this comment.
Makes sense. I think we have two options here:
- I made the recipe a standalone recipe so that end users have to run it on-demand. It will only be applicable to projects that are interested in Mockito 1.x/2.x migrations.
- I am not a fan of this option but here it is. We could add a version parameter to the Java recipe (e.g. a
String maxMockitoVersionoption) and implement a scanning precondition to check the dependency version programmatically.
WDYT?
Contributor
Author
|
I'll make this a draft for now. It's still failing on CI anyway. |
MockitoBestPractices includes RemoveAnnotation for @MockitoSettings(WARN), which conflicts with our recipe when both run in the same composite chain (e.g., JMockitToMockito → MockitoBestPractices → Mockito1to5Migration). Restore UsesType precondition and remove from Mockito1to3Migration chain.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
After migrating from Mockito 1.x, tests fail with
UnnecessaryStubbingExceptionbecause@ExtendWith(MockitoExtension.class)defaults toStrictness.STRICT_STUBS, whereas Mockito 1.x/2.x silently ignored unused stubbings (Strictness.WARN). Detecting which stubbings are truly unnecessary requires runtime analysis, so the practical fix is to add@MockitoSettings(strictness = Strictness.WARN)at the class level to preserve the original behavior.The existing
MockitoJUnitToMockitoExtensionrecipe already handled this when converting aMockitoRule, but had two gaps:@ExtendWith(MockitoExtension.class)was already present alongside aMockitoRule, the recipe removed the rule but did not add@MockitoSettings, silently changing strictness from WARN to STRICT_STUBS.MockitoRuleremaining, just@ExtendWith) were not covered at all — no existing recipe would add the missing@MockitoSettings.Changes
MockitoJUnitToMockitoExtension: Decoupled the@ExtendWithand@MockitoSettingslogic so that@MockitoSettingsis now added even when@ExtendWithis already present (fixes gap 1).New
AddMockitoSettingsWithWarnStrictnessrecipe: Adds@MockitoSettings(strictness = Strictness.WARN)to classes that have@ExtendWith(MockitoExtension.class)but no@MockitoSettingsannotation. This covers classes already migrated without aMockitoRuleto convert (fixes gap 2). Added to theMockito1to3Migrationchain.