You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 2936f17
Browse filesBrowse the repository at this point in the historyBrowse files
Only adopt hasSeconds for isEqualTo in AdoptAssertJDurationAssertions (#1215)
* Stop mapping `Duration#getNano` to `hasNanos` in `AdoptAssertJDurationAssertions`
`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.
* Only convert `isEqualTo` on `Duration#getSeconds` to `hasSeconds` in `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.
* Stop converting `DurationAssert` units in `AdoptAssertJDurationAssertions`
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.
0 commit comments