-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error prone AssertjPrimitiveComparison
for primitive comparisons
#1079
Conversation
Prefer using AssertJ fluent comparisons over logic in an assertThat statement for better failure output. assertThat(a == b).isTrue() failures report 'expected true' where assertThat(a).isEqualTo(b) provides the expected and actual values. This check replaces several refaster rules in order to provide a more concise, more accurate implementation.
Generate changelog in
|
import javax.lang.model.type.TypeKind; | ||
|
||
|
||
final class AssertjSingleAssertMatcher { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I like having this separated out, I imagine there will be a lot more checks that can benefit from this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Carter!
Also nice to be able to delete so many refasters in one go! |
Released 2.37.0 |
This check replaces several refaster rules in order to provide a
more concise, more accurate implementation.
This check supports boxed types and mixed primitive types, in addition to full support for comparisons across all primitives.
==COMMIT_MSG==
Error prone
AssertjPrimitiveComparison
for primitive comparisonsPrefer using AssertJ fluent comparisons over logic in an assertThat
statement for better failure output. assertThat(a == b).isTrue()
failures report 'expected true' where assertThat(a).isEqualTo(b)
provides the expected and actual values.
==COMMIT_MSG==
Possible downsides?
This check assumes the left side of a binary expression is the 'actual' value and the right side is 'expected'. This may not always be the case, but either way the resulting code will provide more actionable output on failure.