Repository navigation
Only adopt hasSeconds for isEqualTo in AdoptAssertJDurationAssertions - #1215
Merged
Merged
Conversation
…nAssertions` `Duration#getNano()` returns only the nanosecond-of-second part, while AssertJ `DurationAssert#hasNanos` compares `toNanos()` of the whole duration. Rewriting `assertThat(d.getNano()).isEqualTo(1)` to `assertThat(d).hasNanos(1)` therefore made a passing assertion fail for any duration of a second or more, so the recipe now leaves `getNano()` assertions alone.
…`AdoptAssertJDurationAssertions` The `getSeconds()` branch did not check which assertion it was replacing, so `assertThat(d.getSeconds()).isGreaterThan(5)` became `assertThat(d).hasSeconds(5)`, turning a comparison into an equality check. The zero handling also only recognised a method call as the `Duration`, so `assertThat(d.getSeconds()).isGreaterThan(0)` on a variable fell through to `hasSeconds(0)`. The recipe now only adopts `hasSeconds` for `isEqualTo`, and turns zero comparisons into `isPositive()`, `isNegative()` or `isZero()` for any `Duration` expression.
…ions` AssertJ `hasSeconds`, `hasMinutes` and the other unit assertions compare the duration truncated to that unit, so rewriting `hasMillis(5000)` to `hasSeconds(5)` weakened the assertion to also pass for 5999 ms. The conversion also turned a zero argument into `hasDays(0)` and threw an `ArithmeticException` from `Math.toIntExact` for values beyond `int` range. The recipe now leaves the unit assertions as written.
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.
AdoptAssertJDurationAssertionscould change what a test checks. It turned comparisons onDuration#getSeconds()into equality, soassertThat(d.getSeconds()).isGreaterThan(5)becameassertThat(d).hasSeconds(5). It mappedgetNano(), the nanosecond-of-second part, tohasNanos, which comparestoNanos()of the whole duration. And it "simplified" units upwards, sohasMillis(5000)becamehasSeconds(5), which also passes for 5999 ms. Along the way a zero argument ended up ashasDays(0), and values outsideintrange threw fromMath.toIntExact.The recipe now only adopts
hasSecondsforassertThat(d.getSeconds()).isEqualTo(x). It leavesgetNano()assertions and the existing unit assertions as written. Zero comparisons such asisGreaterThan(0)still becomeisPositive(),isNegative()orisZero(), now for anyDurationexpression and not only a method call.Fixes item D1 of #1211.