Handle array in mock and verification about pact-js HOT 19 CLOSED

On a side note, you don't ever need to put a like inside an eachLike. Every child of an eachLike will already be matched on type. This doesn't solve your problem, it's just worth mentioning.

from pact-js.

Can you please provide more detail - an example request response payload for starters?

Is this what you are after?

from pact-js.

Thanks @mefellows for always quick reply.

The scenario is that I have an api which is A, and it has consumer B and provider C.
In the contract of A and B, there is something like {"item": ["a1": "v1", "a2", "b2"]}
When verify pact of A, I need to setup mock for C, which needs the exact array.
So in the generated pact between B and C, it has the exact array.
But actually I don't want to verify the exact array between B and C, not even the number of array, only eachLike

The somethinglike works for the mock and only verify the type, but it requires exact number in array
The each like can meet the verification of A and C, but it wouldn't work for mock part to generate the exact array.

Do you have any suggestion?

from pact-js.

I'm still not following, sorry.

Also i'm not sure which component is talking to which, is it:

• C <- B -> A? where B is the consumer of A and a consumer of C? Or
• A -> B -> C where A is the consumer of B which is a consumer of C?

If you have some code I can look at that would be helpful.

from pact-js.

B consumes A, and A consumes C, there is no direct relationship between B and C.

• B generates a spec with array for A.
• A takes that spec, creates mock for C with that exact array, verify pacts from A, then generate spec for C from the mock.
• C take the spec, which includes the exact array. But actually I don't want to verify the exact array, not the numbers in array, not the values in the array, but only eachLike.

But if I setup the mock with eachLike in step 2, step 2 will fail when verify pacts between A and B

from pact-js.

Thanks, this is clearer now.

I think I see the problem here. Are you chaining all of the Pact tests in the one set of tests? Or are they tested in isolation from each other? If the former, then you should separate them.

In step two, when you create the mock for C, why are you matching with the exact array and not using flexible matching (i.e. eachLike(like(...))?

from pact-js.

I separate them into different projects.

what do you mean by eachLike(like(...))?
My understanding is like({"item": ["a1": "v1", "a2", "b2"]}) would give the array to the mock, but when verify in step 3, it will rely on the exact numbers in the array
If I use eachLike({"a1": "v1"}) under item, it won't give the array for mock in step 2.
Is my understanding right?

from pact-js.

Can you please provide a code example that we can look at? You should be able to test an infinite amount of consumer -> provider pairs and stub out their dependencies however you wish.

The code from above doesn't make complete sense to me. The first array is not a valid one, do you want the array to contain objects with key/value pairs, or single values?

like({"item": ["a1": "v1", "a2", "b2"]})

the second matcher eachLike({"a1": "v1"}) will produce an array like this:

[{"a1": "v1"}]

eachLike doesn't care how many array elements there are, so long as they have a minimum (of at least 1, or whatever you specify).

from pact-js.

I'm confused by this data structure {"item": ["a1": "v1", "a2", "b2"]}. Is item an array or a hash?

from pact-js.

@bethesque sorry, it should be something like {"items": [{"field": "value1"}, {"field": "value2"]}, array of objects in an object.

from pact-js.

I'm sorry @lippea it's too hard to get my head around. Can you create an executable example on github please. @mefellows what do you think about making an e2e example codebase like the ruby one? (in your free time...)

from pact-js.

There kind of is this which uses all of the features. I'll typically modify this and share branches to demonstrate repros.

from pact-js.

The benefit of having it in a separate repo is that you can have a travis build to run the example that works as soon as it's forked, and have the build outcome visible to everyone. It's getting quite tedious trying to setup and maintain development environments for all the languages now!

from pact-js.

Closing due to inactivity.

from pact-js.

Hi, I have a similar question. I'll try to explain:

I have a test on my consumer side which needs an array as response:
items: [ { id: 1}, { id: 2} ]
I need the ids to be different and I need them to match a certain regex. But then when I verify the pact with the provider I don't care how many items there are. My current implementation generates a pact like this:

"response": {
        "status": 200,
        "body": {
          "items": [
            { "id":  "1" },
            { "id":  "2" }
          ]
        },
        "matchingRules": {
          "$.body.items[0].id": {
            "match": "regex",
            "regex": "\\d+"
          },
         "$.body.items[1].id": {
            "match": "regex",
            "regex": "\\d+"
          }
        }

but then the verification fails because it expects exaclty 2 items to be returned.

Is there a way to to this? My ideal solution would be something like this:

term({
    generate: [ { id: 1}, { id: 2} ],
    matcher: eachLike(..., { min: 1})
  });

but I don't think that's possible?

from pact-js.

To my knowledge, that specific case is not possible. I would suggest updating the consumer test to not care about having two items with specifically different ids. Why do you need the consumer to expect an array of two specific IDs? It's of particular concern if the verification is not matching the real expectations of the consumer.

I would think something like this would be the matcher you need:

"items": eachLike({id: 1}, {min: 2})

This won't care if the provider returns 2 or 200, unlike your current matcher.

from pact-js.

I feared as much. Maybe I need to improve my consumer tests to accomodate this case.

I need the two items to have different ids because the business logic on the consumer side (a frontend application) differs when there are duplicate ids. I can test this case by using eachLike(.., {min: 2}) , but I don't know how to test the other case, where the ids differ. Maybe id is a bad example here because they shouldn't be duplicated, but let's say the frontend logic depends on an amount being higher or lower than a certain treshold. Then I need the provider to return an array with two differing amounts (e.g. [ { amount: 99} , { amount: 101} ] so I can test if the logic of this treshold works.

Additionally, if I use eachLike({ id: 1} , {min: 2}), the resulting contract only matches on type, no? I can't make the value of this id match a certain regex?

from pact-js.

@gvdp you can nest a regexp matcher inside a like, no problems.

Personally, I would just use a unit test (no pact) for checking boundary conditions. When you start caring too much about the actual values inside the resources, pac tests becomes a bit brittle, and you end up with an explosion of interactions to verify. Use pact to make sure you understand the shape of the document, and then use normal unit tests to check variations within that.

from pact-js.

Ok, I'll have to try the regex inside the like.

Thanks for the help! I think I can indeed test my specific case in a unit test. Our consumer is a front-end app and we're just getting started with doing unit tests for those but it's good to think about these cases and to realize they can actually be tested in this unit test phase.

from pact-js.