Repository navigation
Keep JUnit deltas when converting assertEquals, assertNotEquals and assertArrayEquals to AssertJ - #1216
Merged
Conversation
…tThat` `assertEquals(100, elapsed, 10)` with a `long elapsed` became `assertThat(elapsed).isEqualTo(100)`, silently dropping the tolerance, and `assertEquals(1.5, count, 0.5)` became an `isEqualTo` that can never pass. JUnit widens the actual to the `float` or `double` delta type, so the recipe now casts it the same way and keeps the tolerance, as in `assertThat((float) elapsed).isCloseTo(100, within((float) 10))`. The delta is only dropped when it is a literal zero and both values are `int` or `long`.
…s` and `assertArrayEquals` Like `assertEquals` before #911, `JUnitAssertNotEqualsToAssertThat` and `JUnitAssertArrayEqualsToAssertThat` decided whether the third argument was a delta from that argument's own type. So `assertNotEquals(0.0, d, 0)` became `.as(0)`, and `assertNotEquals(5, count, 1.0)` called an `isNotCloseTo(int, Offset<Double>)` that doesn't exist. Both now use the resolved parameter type and cast the actual and delta where JUnit widened them, sharing the helpers with `JUnitAssertEqualsToAssertThat`.
timtebeek
changed the title
assertEquals, assertNotEquals and assertArrayEquals to AssertJ
23 of 76 tasks
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.
JUnitAssertEqualsToAssertThatdropped any delta when the actual was anintorlong, soassertEquals(100, elapsed, 10)becameassertThat(elapsed).isEqualTo(100)and a test that tolerated a little jitter started failing. With a fractional expected value, as inassertEquals(1.5, count, 0.5), the result was anisEqualTothat could never pass. JUnit widens the actual to thefloatordoubledelta type, so the recipe now casts it the same way and keeps the tolerance:assertThat((float) elapsed).isCloseTo(100, within((float) 10)). The delta is only dropped when it is a literal zero and both values areintorlong, as in the existingassertEquals(50L, getSummation(), 0.0)case.JUnitAssertNotEqualsToAssertThatandJUnitAssertArrayEqualsToAssertThatstill decided between a delta and a message from the third argument's own type, the problem #911 fixed forassertEqualsonly. SoassertNotEquals(0.0, d, 0)becameassertThat(d).as(0).isNotEqualTo(0.0), andassertNotEquals(5, count, 1.0)called anisNotCloseTo(int, Offset<Double>)that doesn't exist. Both now look at the resolved parameter type and share the cast handling, givingassertThat(d).isNotCloseTo(0.0, within((double) 0))andassertThat((double) count).isNotCloseTo(5, within(1.0)). I compiled the new test outputs against AssertJ 3.27.4 to check that these overloads exist.Fixes item D2 of #1211.