WIP: Use custom gomega matcher for protobuf equality
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.
A failed match produces output similar to the following:
[FAILED] Expected
ChaincodeMessage{
type: TRANSACTION
payload: "\n\x04arg1\n\x04arg2"
txid: "tx-id"
proposal: {
proposal_bytes: "signed-proposal-bytes"
signature: "signature"
}
channel_id: "channel-id"
}
to equal
SignedProposal{
proposal_bytes: "signed-proposal-bytes"
signature: "signature"
}
Type of change
- Bug fix
- New feature
- Improvement (improvement to code, performance, etc)
- Test update
- Documentation update
Description
Additional details
Related issues
@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())