pact-foundation/pact-js

`eachLike` behaves like `atLeastOneLike` when min is not explicitly set - contrary to documentation

timvahlbrock opened this issue · 5 comments

Software versions

Please provide at least OS and version of pact-js

  • OS: Win 11
  • Consumer Pact library: 12.4.0
  • Provider Pact library: irrelevant
  • Node Version: 21.6.0

Issue Checklist

Please confirm the following:

  • I have upgraded to the latest
  • I have the read the FAQs in the Readme
  • [ x I have triple checked, that there are no unhandled promises in my code and have read the section on intermittent test failures
  • I have set my log level to debug and attached a log file showing the complete request/response cycle (not possible due to GDPR on main project, can generate log using reproduction repro if required)
  • For bonus points and virtual high fives, I have created a reproduceable git repository (see below) to illustrate the problem

Expected behaviour

eachLike sets a min of 0 by default or the documentation is corrected.

Actual behaviour

eachLike sets a min of 1 by default. The documentation states that the length is not checked. Likely introduced in 974d247#diff-884c1c7cbdaafa772a7a428e0ca83ce1fc58f03972dfa0fabcb89106d6ac35f5

Steps to reproduce

Use eachLike for an array property. Run pact consumer tests. See the property received a min of 1. Should look something like this:

            "$[*].theArrayProperty": {
              "combine": "AND",
              "matchers": [
                {
                  "match": "type",
                  "min": 1
                }
              ]
            },
            

Relevant log files

Please ensure you set logging to DEBUG and attach any relevant log files here (or link to a gist).
As described, I can add logs from a reproduction repo if desired, but I think this might not be required here.

I do understand why it is not safe to allow empty arrays, as the provider might 'cheat' itself into matching the contract by providing an empty array. But if I get this correctly, eachLike currently mostly behaves like atLeastOneLike, or atLeastLike. Maybe the documentation might needs updating, maybe eachLike should be removed altogether.

Maybe eachLike should be made into an alias of atLeastOneLike but also be documented as such.

Personally favor aliasing over removing, as eachLike still communicates, that this value might be empty in production.

Perhaps. eachLike was the original matcher for arrays and this has always been the semantics of it. New matchers such as atLeastLike, atMostLike and constrainedArrayLike really capture a wider set of use cases.

I agree, eachLike feels a bit lost with the introduction of these additional matchers.

Maybe eachLike should be made into an alias of atLeastOneLike but also be documented as such.

They aren't actually the same thing (different signatures), so aliasing them won't address the problem. They can't also be made to be the same without a breaking change, and that's probably overkill. The simplest would be to improve the doc string to indicate it always has a min of 1, or error if you try to set it less than 1.

Closed by #1208.