-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Test utility for BytesReference equality
#138668
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
Conversation
Today if you assert two `BytesReference` objects are equal, and they aren't, then the test output is unhelpful because `BytesReference` instances do not include their contents in their default string representations. This commit introduces a new matcher specifically for testing `BytesReference` instances for equality which generates more useful output.
|
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
|
Review notes: apart from |
joshua-adams-1
left a comment
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.
LGTM. General question: how did you find every instance of assertEquals that had two ByteReference's passed in, or an existing assertThat that had equalsTo(ByteReference) ? When I look on Intellij, I see a function definition such as private static boolean isEquals(Object expected, Object actual) { which isn't helpful in this case.
| import java.util.Objects; | ||
|
|
||
| public enum BytesReferenceTestUtils { | ||
| ; |
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.
[Nit] Extra semicolon?
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.
That's required - omitting it is a compile error 😁
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.
Is using enums for static utilities a pattern we're using now? Curious about this choice vs an abstract class or final class with a private constructor to accomplish the same thing.
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.
We do both and this is my preference purely because it involves less boilerplate than declaring a private constructor.
SSR is incredibly powerful. I used it extensively in our work to remove old usages of unsupported transport versions. |

Today if you assert two
BytesReferenceobjects are equal, and theyaren't, then the test output is unhelpful because
BytesReferenceinstances do not include their contents in their default string
representations. This commit introduces a new matcher specifically for
testing
BytesReferenceinstances for equality which generates moreuseful output.