Skip to content

Fix assertEquals delta misinterpreted as message in AssertJ conversion#1000

Merged
timtebeek merged 1 commit into
mainfrom
tim/fix-assertequals-delta-conversion
May 18, 2026
Merged

Fix assertEquals delta misinterpreted as message in AssertJ conversion#1000
timtebeek merged 1 commit into
mainfrom
tim/fix-assertequals-delta-conversion

Conversation

@timtebeek
Copy link
Copy Markdown
Member

@timtebeek timtebeek commented May 18, 2026

Summary

  • Assertions.assertEquals(7f, rect.getHeight(), 0) was converted to assertThat(rect.getHeight()).as(0).isEqualTo(7f) — the int literal 0 (the delta) was treated as the description. The recipe was inspecting the argument expression type, but the compiler widens 0 to float to resolve assertEquals(float, float, float), so the third position is actually a delta.
  • The discriminator now inspects the resolved method's parameter type via mi.getMethodType().getParameterTypes().get(2) instead of the argument's expression type.
  • When the literal would otherwise resolve to a mismatched AssertJ within(...) overload (e.g. within(0)Offset<Integer> against isCloseTo(float, Offset<Float>)), an explicit cast is inserted: within((float) 0).

After the fix, Assertions.assertEquals(7f, rect.getHeight(), 0) becomes:

assertThat(rect.getHeight()).isCloseTo(7f, within((float) 0));

Test plan

  • New test floatWithIntegerLiteralDelta covers the reported case
  • All 12 existing JUnitAssertEqualsToAssertThatTest cases still pass (double/float deltas, boxed Double.valueOf(...), integral actual with floating delta, message variants)

When the delta argument was a non-floating-point literal (e.g. `0`),
`assertEquals(7f, getHeight(), 0)` was converted to
`assertThat(getHeight()).as(0).isEqualTo(7f)` because the recipe checked
the argument's expression type instead of the resolved method's parameter
type. The compiler widens `0` to `float` to resolve
`assertEquals(float, float, float)`, so the third argument is a delta.

Now inspects the resolved parameter type, and inserts an explicit cast on
the `within(...)` argument when the literal would otherwise resolve to a
mismatched `Offset<T>` overload.
@github-project-automation github-project-automation Bot moved this to In Progress in OpenRewrite May 18, 2026
@timtebeek timtebeek merged commit da4dd54 into main May 18, 2026
1 check failed
@timtebeek timtebeek deleted the tim/fix-assertequals-delta-conversion branch May 18, 2026 16:52
@github-project-automation github-project-automation Bot moved this from In Progress to Done in OpenRewrite May 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

Invalid conversion when using delta in float comparison

1 participant