hi there, is there a way to define PactDslWithProvided builder with optional arrays ? { "data": { "titles": [ { "titleId": "1234", "parenttitleId": "5678", "titleName": "test", "titleOwner": "xyzb", "titleArchitect": "abcde", "titleLeads": [ //optional array -- how to mention this - if exist - example to be of this type , if not - ignore the verification { "lead1": "xyz", "isEndorsed": true }, { "lead2": "abcd", "isEndorsed": false } ] }, { "titleId": "12345", "parenttitleId": "5678", "titleName": "test", "titleOwner": "xyzba", "titleArchitect": "abcdef" } ] } }

Use the

eachLike

function

for “optional”, please also see the below link to properly cover your use case 👇 (howtooptional)

this still fails at provider end if the optional array 'titleLeads' not returned:

.body(new PactDslJsonBody().object("data")
                                .minArrayLike("titles", 1)
                                .stringType("titleId", "abcd01")
                                .stringType("parentTitleId", "abcd01")
                                .stringType("titleName", "ABCD")
                                .stringType("titleOwner", "abcd01")
                                .eachLike("titleLeads")
                                .stringType("employeeId")
                                .booleanType("isEndorsed")
                                .closeObject()
                        .closeArray()
                .closeObject()
        .closeArray())
.toPact();

Oh, you mean it is not present at all. No, it won't support that. Refer to the link posted above.

Based on the FAQ, looks like there is no option to set the optional ..

We don't support optional values.

got it ! and the reasoning behind that .. however if we check for say retrieve all end point where in the first item might have or might not have the optional array and hence in this case - looks like there is no way to verify it

You need to create two tests, one with the value and one without. Then define a different provider state for each case.

yeah got that.. but definitely all microservice will have retrieveall list endpoint where in this specific need arises ! and looks like as of now there is no way to verify in pact ..

Pact won't support optional fields, you need to use tests for the different cases

A key point here is that you’re not describing the response schema in your pact test. You are defining a complete example. Pact is contract-by-example, not contract-by-schema. A matcher doesn’t say “this might be in the response”, it says “this test covers all responses that pass this matcher”.

I wonder if in this scenario (and possibly many others) we should start using the word “test” or “unit test”, instead of “Pact test” i.e. how do you write a unit test that A is either an X or a Y? You write two tests. You don’t write a single unit test that has one variant and if it passes call it done. You write a second one for the other variant to cover both branches

I like it.

thanks for the details.. I completely understand what you mean and pact test is exactly similar to unit test with specific examples .. However, in this case - I don't understand how to write it specifically just for one data (if the end point is to retrieve all lists and it does retrieves for all data. Response : first object is array without optional array and second object is array with optional array and its values .. Note: if I remove the optional array in the builder - it doesnt verify this array at all and the test anyway passes. However, if I do add the optional array - test always fails because the intention of the end point is to retrieve for all data and not just one data (are we expected to write the builder with all array of responses?)

You do this with provider states

It is a common provider state in this case

test one: • State “titles don’t have titleLeads” • Request • Response expects no title leads test two: • State “titles have titleLeads” • Request • Response expects title leads

whatever you mentioned is applicable for my endpoint - get for titleLead1, get for titleLead2 etc .. (for which I have written two different states)

Why not?

as the response can have both

For get all, you could use the arrayContains matcher - one with and one without.

which means if the response is supposed to return two titles - I should have two array explicitly with arrayContains matcher ?

getallTitleLeads - returns both titles one with and one without

Yes. You could use two states: • “No titles have titleLeads” • “All titles have titleLeads” Or you could use “One title with titleLeads, and one title without titleLeads”

unfortunately getallTitleLeads - doesnt have any input param to return me only titles with titlesLeads and viceversa

No, no

ok got you .. because we use mocking in the provider end - you saying use different provider state and mock the response to return two different states

Yes.

hmm... unfortunately in my case - we are not using mocking for now in the provider end (I know its not 100% right, still.. ) as we are implementing contract testing for the existing microservices too - we pointing to live endpoint in the provider instead of mock (which doesnt give me responses for specific state).. and single state with both response types (this end point have got multiple such optional arrays and returns 100s of response with different combination - hence not easy to explicitly define the expectation)

In that case, I would define it with either the specific exact test data that you are setting up, or I would define it with the arrayContains matcher with both types of response object (I’m not familiar with the JVM DSL, so I can’t give you an exact answer there)

Sure nws … I got the idea though .. thanks