fabric icon indicating copy to clipboard operation
fabric copied to clipboard

WIP: Use custom gomega matcher for protobuf equality

Open bestbeforetoday opened this issue 1 year ago • 1 comments

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 avatar Aug 27 '24 18:08 bestbeforetoday

@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 avatar Aug 27 '24 20:08 pfi79

@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())

bestbeforetoday avatar Aug 29 '24 08:08 bestbeforetoday