Hey folks, a somewhat newbie question: What if the...
# general
s
Hey folks, a somewhat newbie question: What if the same value is used in multiple places across request and response? An example: we send a request to create a resource with id x123. The response can be smth like:
Copy code
{
  "id": "x123",
  "url": "<https://example.com/api/v1/entity/x123>",
  "fullName": "entity-x123"
}
How can this be modeled in pact? If each field just specifies a regex like
x\d+
or smth, and
x123
as an example, is this enough?
m
What usually matters in a contract testing sense, is that the shape of the response is correct - usually, the specific values donโ€™t
so yes, if your client expects
id
to be a regex of a specific type, then that could suffice. Be careful not to artificially constrain the response types (see this page, and this specific point)
b
To elaborate a smidge, it also depends (in this example) which values are load-bearing, and which are coincidentally the same. E.g. the
fullName
attribute is probably not being parsed or split on the
-
, so it only cosmetically seems to need the same value.
๐Ÿ’ฏ 1
On the other hand, if it's important that some of the input values appear in the output, you can set those expectations in the contract (by using stricter matchers, like exact value, instead of flexible type matching).
๐Ÿ‘ 1
s
thanks folks! The point about "what would break the consumer if it changed" is valuable indeed. I'm thinking in the example above the consumer probably doesn't care that the url contains the ID - it seems to be an implementation detail on the provider side; and consumer just cares that it is a valid url.
๐Ÿ‘ 1