Repository navigation
Add UsesMethod and UsesType preconditions to recipes that visit every file - #1227
Merged
Merged
Conversation
23 of 76 tasks
timtebeek
force-pushed
the
tim/add-missing-usesmethod-preconditions
branch
from
October 25, 2026 12:48
9b2932d to
a58536f
Compare
…it every source file
timtebeek
force-pushed
the
tim/add-missing-usesmethod-preconditions
branch
from
October 25, 2026 12:52
a58536f to
53b9682
Compare
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
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.
Eleven recipes visited every Java (or Kotlin) source file without a precondition, so they walked whole trees,
JUnitTryFailToAssertThatThrownByeverytryblock, even in files that could never change. The option-driven AssertJ recipes multiply this:SimplifyChainedAssertJAssertionis instantiated about 63 times in YAML andSimplifyAssertJAssertion8 times.Each visitor is now wrapped in
Preconditions.check(..), reusing the matchers the visitor itself checks, so the gate can't exclude anything the visitor changes:UsesMethodon the existing static matcher:AssertEqualsBooleanToAssertBoolean,AssertFalseNegationToAssertTrue,AssertNotEqualsBooleanToAssertBoolean,AssertThatBooleanToAssertJ.Preconditions.or(UsesMethod..)over the visitor's matchers:JUnitTryFailToAssertThatThrownBy(the fourfail(..)matchers) andAssertTrueInstanceofToAssertInstanceOf. The latter built its two matchers on every method invocation; they are nowprivate static finalfields.MockConstructionToTryWithResourcesis gated on theScopedMock.close()matcher rather thanmockConstruction(..). Both of its transformations need aclose()call, and removing a redundantclose()inside try-with-resources does not needmockConstruction(..)in the file.SimplifyAssertJAssertiongates on itsassertToReplacematcher, andSimplifyChainedAssertJAssertionon both its chained-method andassertToReplacematchers. These matchers were already built from the options ingetVisitor(), so a null option still gives a matcher that never matches (a no-op, as before) and adds no new failure mode.MinimumJreConditionsusesPreconditions.oroverUsesTypefor the four JRE condition annotations, andCleanupKotlinJUnit5AssertionImportsusesUsesTypeonorg.junit.jupiter.api.Assertions. I added a Kotlin test to confirm that the type gate still lets through a file whoseAssertionsimport is unused (an unused wildcard import also passed when I checked it locally).Nothing from the item was skipped.
Verified with
./gradlew test --tests 'org.openrewrite.java.testing.assertj.*' --tests '...cleanup.*' --tests '...hamcrest.*' --tests '...junit5.*' --tests '...junit6.*' --tests '...mockito.*': 1868 tests, 0 failures, 6 skipped. This covers the tests for every touched recipe, the YAML instances of the AssertJ recipes, and the composites that include the others.Fixes item M1 of #1211.