Hi there, what would be recommended for the follow...
# pact-js
d
Hi there, what would be recommended for the following scenario? I am writing a PACT for an API call which retrieves information related to a footer, I want to ensure that it has at most 2 rows of data, each row can contain 4 columns. Each item within a column can be of varying data structures so using a like matcher is not fit for purpose, instead I am using
arrayContaining
. I can constrain the outer array (rows) however I cannot constrain the inner columns array. (If I use a
constainedArrayLike
, this implies that the
items
must appear in every single column, which they do not. (See inline comment in code below).
Copy code
body: constrainedArrayLike(
    arrayContaining({ # Cannot constrain here, but must use arrayContaining to allow the below state.structure to appear in at least one of the columns. Using any other constained matcher implies it must appear in all columns
        columnAlignment: like('left'),
        items: arrayContaining(like(state.structure)),
    }),
    MIN_ALLOWED_ROWS,
    MAX_ALLOWED_ROWS, // At most MAX_ALLOWED_ROWS can be included in the response
),
m
So are you saying a data structure like this?
Copy code
[
  {"a": 1, "b": "string", "c": true, "d": null}, // allows four columns 
  {"a": {/* object allowed?*/}, "b": "string"}   // only two columns
]
Is the limitation on rows a constraint of your consumer or provider? i.e. what would happen if you got more than 2 rows? 0 rows? (I’m trying to understand if this is a functional test, and potentially a test that is too constraining on the provider)
d
Thanks for getting back to me @Matt (pactflow.io / pact-js / pact-go)! Here is an example of what the JSON response may look like.
Copy code
[ # Array size of 2 at most
    [ # Array size of 4 at most
        {
            "columnAlignment": "left",
            "items": [
                {
                    "type": "structure1",
                    "attribute": "value",
					"attribute": "value"
                },
                 {
                    "type": "structure2",
                    "attribute": "value",
                },
                 {
                    "type": "structure3",
                    "attribute": "value",
					"attribute": "value"
					"attribute": "value"
                },
            ]
        },
        {
            "columnAlignment": "left",
            "items": [
                {
                    "type": "structure4",
                    "attribute": "value",
                },
            ]
        },
        {
            "columnAlignment": "left",
            "items": [
                 {
                    "type": "structure1",
                    "attribute": "value",
					"attribute": "value"
                },
				{
                    "type": "structure4",
                    "attribute": "value",
                },
				
            ]
        }
    ]
]
I'd say the limitation is on our (the consumer) side, we will build our application against the 2x4 grid, any more and it may not display content properly, violate WCAG guidelines etc. The provider will not be developing their API for another few months, so yes we're purposefully being constraining on the provider (happy to be challenged on this if I'm thinking about this in the wrong way). So using the above, let's say I want to ensure that
when a footer exists which contains the structure4 type,
what would you recommend? It doesn't exist in the first column, only 2 & 3 (which is fine), all I'm really wanting to test here is that it's structure of the entire response is the 2x4 grid and my
structure4
json object is somewhere and matches it's required structure