Closed bestbeforetoday closed 1 month ago
@bestbeforetoday Sorry, I see your change is still in the draft. But I'll ask you a question right away. Will you have a proposal for mixed structures, where there are both proto and non-proto fields.
For example: https://github.com/hyperledger/fabric/blob/main/core/ledger/kvledger/txmgmt/validation/batch_preparer_test.go#L453 https://github.com/hyperledger/fabric/blob/main/core/ledger/pvtdatastorage/retroactive_hashed_index_test.go#L78
@pfi79 Covering both protobuf and non-protobuf elements in a single matcher is definitely possible. It would essentially mean duplicating the behaviour of the existing gomega Equal matcher and extending it to handle protobuf messages using proto.Equal. That is (much) more work than I was planning to tackle in this PR. Instead I was planning just what is implemented here — a matcher for protobuf messages to avoid the need for contributors to remember and use a pattern such as:
Expect(proto.Equal(value1, value2)).To(BeTrue())
The standard gomega Equal matcher is not reliable when used with protobuf messages since they can be logically equal while containing different implementation field values. This change implements a custom ProtoEqual matcher that uses proto.Equal for reliable equality checks.
This implementation enables the following:
which is a more idiomatic alternative to:
In addition, a failed match produces output similar to the following, which is significantly more informative than a message simply stating that false is expected to be true: