PactDslJsonBody#eachKeyMappedToAnArrayLike does not work on "nested" property

[flyinfish]

PactDslJsonBody#eachKeyMappedToAnArrayLike(exampleKey) works as expected on "level-0":

• create pact:
  https://github.com/maxant/pactexamples/blob/master/src/test/java/ch/maxant/tullia/pactexamples/EventsRepositoryDictionaryArrayConsumerTest.java#L45
• provider-verification:
  https://github.com/maxant/pactexamples/blob/master/src/test/java/ch/maxant/tullia/pactexamples/ProviderTest.java
  https://github.com/maxant/pactexamples/blob/master/app.js#L43

But if we move the same structure in a property "events" the verification fails:

• create pact:
  https://github.com/maxant/pactexamples/blob/master/src/test/java/ch/maxant/tullia/pactexamples/EventsRepositoryDictionaryNestedArrayConsumerTest.java#L42
• provider-verification:
  https://github.com/maxant/pactexamples/blob/master/src/test/java/ch/maxant/tullia/pactexamples/ProviderTest.java
  https://github.com/maxant/pactexamples/blob/master/app.js#L68

1. every property is validated against structure
   $.body.newFeature -> Expected ant=List(Map(title -> ant)) but was missing
2. the validation ist not "by example" as expeted and working in first case but strict
   $.body.events -> Expected ant=List(Map(title -> ant)) but was missing

[flyinfish]

Bug in V 3.3.7 and 3.5.0.beta3

[maxant]

The problem with the "newFeature" attribute is that the consumer doesn't require it, but the pact fails when the provider runs it, since it seems to require that the attribute is mentioned in the pact.

[maxant]

@flyinfish sorry, I think I broke your line numbers with my last commits :-(

[joelgithub]

Are there any planned fixes for this issue? It's really problematic for us as well.

[mboudreau]

@uglyog @mefellows @bethesque
Anyone have any insights for this? I can try to fix it myself, but I don't have enough context to make my effort efficient.

[bethesque]

@uglyog will be able to help when he has time

[joelgithub]

Just for my own understanding, Is this a bug that has a fix within v.3 spec?

[uglyog]

@joelgithub I added an item to the V4 WIP for this feature, but I don't think any of the other Pact implementations support it.

[mboudreau]

Ron, any potential workaround for his situation that would work?

…

On Sun., 11 Mar. 2018, 12:01 pm Ronald Holshausen, ***@***.***> wrote: @joelgithub <https://github.com/joelgithub> I added an item to the V4 WIP for this feature, but I don't think any of the other Pact implementations support it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#401 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjA5CpY6Z65mrssFNVJqNSbgvz42r_2ks5tdHdbgaJpZM4M4uGP> .

[uglyog]

The problem is that this behaviour may have been introduced due to a workaround for #313, so in essence it would be a workaround for a workaround. It is also not a trivial problem to solve in a general way, hence the amount of time this issue has been open.

The best solution would be to make it explicit with a new type of matcher, but that would be specific to the JVM version and would not be supported with any other language. I'll going to try replicate the problem and see if I can work something out in the short term that does not make the matching logic worse.

[mboudreau]

Right, so this would still be an issue for all ruby based implementations..

…

On Sun., 11 Mar. 2018, 12:30 pm Ronald Holshausen, ***@***.***> wrote: The problem is that this behaviour may have been introduced due to a workaround for #313 <#313>, so in essence it would be a workaround for a workaround. It is also not a trivial problem to solve in a general way, hence the amount of time this issue has been open. The best solution would be to make it explicit with a new type of matcher, but that would be specific to the JVM version and would not be supported with any other language. I'll going to try replicate the problem and see if I can work something out in the short term that does not make the matching logic worse. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#401 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjA5Dld5T0tlk7BeENYm-_eJMxCLEOTks5tdH4igaJpZM4M4uGP> .

[uglyog]

Good news is that the root of this issue was in the Java DSL which was not generating the correct matchers. I have corrected this.

I am still going to implement the correct solution, which will be disabled behind a feature toggle.

[uglyog]

3.5.14 has been released with the corrected DSL method

[joelgithub]

Thanks @uglyog ! Will verify if this fixes the problem.

[joelgithub]

I did a test and it seems to not verify the inner structure of the array objects.

This is my dsl:

dslBody
            .date("date", "yyyyMMdd'T'HHmmss")
            .stringMatcher("system", ".+", "systemname")
            .object("data")
            .eachKeyMappedToAnArrayLike("subsystem_name")
            .stringType("id","1234567")
            .closeArray()
            .closeObject()
        ;

And when running the provider test responding with:

{
  "date": "19880101T120101",
  "system_name": "s1",
  "data": {
    "sub": [
      {
        "hop":"san"
      }
    ]
  }
}

It passes without complaints. I expected it to fail on the missing "id" attribute of the array object.

This is the generated pact file:

{
    "provider": {
        "name": "provxxx"
    },
    "consumer": {
        "name": "consxxx"
    },
    "interactions": [
        {
            "description": "GET data for system",
            "request": {
                "method": "GET",
                "path": "/xxxx"
            },
            "response": {
                "status": 200,
                "headers": {
                    "Content-Type": "application/json"
                },
                "body": {
                    "date": "20000131T140000",
                    "system": "systemname",
                    "data": {
                        "subsystem_name": [
                            {
                                "id": "1234567"
                            }
                        ]
                    }
                },
                "matchingRules": {
                    "header": {
                        "Content-Type": {
                            "matchers": [
                                {
                                    "match": "regex",
                                    "regex": ".*application/json.*"
                                }
                            ],
                            "combine": "AND"
                        }
                    },
                    "body": {
                        "$.date": {
                            "matchers": [
                                {
                                    "match": "date",
                                    "date": "yyyyMMdd'T'HHmmss"
                                }
                            ],
                            "combine": "AND"
                        },
                        "$.system": {
                            "matchers": [
                                {
                                    "match": "regex",
                                    "regex": ".+"
                                }
                            ],
                            "combine": "AND"
                        },
                        "$.data.*": {
                            "matchers": [
                                {
                                    "match": "type",
                                    "min": 0
                                }
                            ],
                            "combine": "AND"
                        },
                        "$.data.*[*].id": {
                            "matchers": [
                                {
                                    "match": "type"
                                }
                            ],
                            "combine": "AND"
                        }
                    }
                },
                "generators": {
                    "body": {
                        "$.date": {
                            "type": "Date",
                            "format": "yyyyMMdd'T'HHmmss"
                        }
                    }
                }
            },
            "providerStates": [
                {
                    "name": "That data exist"
                }
            ]
        }
    ],
    "metadata": {
        "pact-specification": {
            "version": "3.0.0"
        },
        "pact-jvm": {
            "version": "3.5.14"
        }
    }
}

[uglyog]

Ok, will have a look using your example.

[rholshausen]

/jira ticket

[github-actions]

👋 Thanks, Jira [PACT-593] ticket created.

[rholshausen]

Closing this, as this functionality has been replaced with the Values matcher. Using the given DSL, the matching on the given provider response works as expected with the following errors:

$: Actual map is missing the following keys: system
$.data.sub.0: Actual map is missing the following keys: id