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
Compare public elements of struct #1309
Compare public elements of struct #1309
Conversation
Co-authored-by: Anthony Chang <anthony-chang@users.noreply.github.com>
…testify into compare_public_elements_of_struct
@boyan-soubachov Would be great if you could take a look at this and merge if it looks good! |
// ObjectsExportedFieldsAreEqual determines if the exported (public) fields of two structs are considered equal. | ||
// If the two objects are not of the same type, or if either of them are not a struct, they are not considered equal. | ||
// | ||
// This function does no assertion of any kind. |
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.
🤔 Given that this is the assert package, would it not make sense if we did assert?
Right now the functionality of this is more of a helper function, should we not just change it to an assert function that asserts whether object_a
's exported fields == object_b
's exported fields?
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 have another function that is added further down in the file called EqualExportedValues
that actually does the assertion by calling this ObjectsExportedFieldsAreEqual
helper function.
We thought that it would make sense to split up the logic for actually doing the comparison (and put it into a helper function) from the actual assertion function. This seems to be the approach that is used for equality comparisons with a ObjectsAreEqual
helper function that is then called by the Equal
function that actually does the assertion.
Ping is this blocked - if so what needs to be figured out? Is there any workaround to testing equality of protobuf structs (only the fields we actually care about)? |
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.
Thank you for the contribution :)
@mchlp This is awesome! However, after trying it out now, I notice that unexported fields are still compared in some cases. This is with a Protobuf var myDate = date.Date{
Year: 2023,
Month: 3,
Day: 15,
}
suite.assertListMealsResponse(ctx, user, &myDate, &my_protobuf_definitions.ListMealsResponse{
Date: &myDate,
... which fails like this:
I also noticed that the diff will contain all unexported fields. Meaning that if you are comparing nested Protobuf messages, the terminal will be very noisy. This is what I see (truncated):
|
Here is a proposed fix by me: #1379 |
Summary
Adds a method to check for equality of two structs of the same type by checking ONLY the exported (public) fields.
Changes
ObjectsExportedFieldsAreEqual
method inassert/assertions.go
that contains core code for the functionality (loops through fields of the struct using thereflect
library and only compares fields that are exportedEqualExportedValues
method inassert/assertions.go
that calls theObjectsExportedFieldsAreEqual
method and contains assertion related code that logs the appropriate message on failureTestObjectsExportedFieldsAreEqual
inassert/assertions_test.go
Motivation
There are use cases where users want to compare only the public fields of two struct objects (when they only care about the public interface of the object and the internal private representation does not matter). This added method provides users the ability to do this with the
testify
library.Example Usage:
The method also works with nested structures, where
ObjectsExportedFieldsAreEqual
is recursively called for nested fields that are of type struct, orObjectsAreEqualValues
are called on non-struct type fields.Related issues
Closes #1033