You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Setting expectations for requests should be as strict as possible since we own the code and own the data to verify our system's behaviour - Choosing the right type of matching.
Typically, exact matching is most appropriate for Pact tests on the consumer
side that are running at the unit test level. The same person is responsible for
both the expectation and the actual request, so making sure that they match should
be straightforward.
But sometimes when sending requests, specifically POST requests, sometimes we need to generate a random value and send to the provider. This can be an issue when we want to verify the key is being sent, but we can't guarantee the value to be sent.
💬 Narrative
When setting up expectations for requests
I want to be able to use matchers
So that requests don't fail when generated values are being sent
🏗 Design
classSomePactTest:PactTestCase{classSomePactTest:PactTestCase{func testAnInteraction()asyncthrows{try builder
.uponReceiving("A request to create a record").given("A record does not exist").withRequest(method:.POST, path:"/records"){ request in// #start of feature requesttry request
.jsonBody(.like(["identifier":.uuid("b425456a-2450-43ab-86cf-1a8b9d3981c4",.lowerCaseHyphenated),"anotherIdentifier":.randomUUID(),// using an example generator // https://github.com/pact-foundation/pact-specification/tree/version-3#introduce-example-generators"type":.oneOf(["A","B","C"]),"name":.like("some string"),"value":.number(5)]))// #end }.willRespond(with:201){ resonse intry response.jsonBody(.like(["result":.like("ok")]))}}}
✅ Acceptance Criteria
GIVEN defining expectations for requests WHEN matchers and/or example generators are used THEN they are reflected in the Pact contract and considered when verifying the interactions (running Pact test) (eg: request doesn't fail if expected uuid doesn't match the sent uuid)
🚫 Out of Scope
The text was updated successfully, but these errors were encountered:
🗣 Context
Setting expectations for requests should be as strict as possible since we own the code and own the data to verify our system's behaviour - Choosing the right type of matching.
But sometimes when sending requests, specifically
POST
requests, sometimes we need to generate a random value and send to the provider. This can be an issue when we want to verify thekey
is being sent, but we can't guarantee the value to be sent.💬 Narrative
When setting up expectations for requests
I want to be able to use matchers
So that requests don't fail when generated values are being sent
🏗 Design
✅ Acceptance Criteria
GIVEN defining expectations for requests
WHEN matchers and/or example generators are used
THEN they are reflected in the Pact contract
and considered when verifying the interactions (running Pact test) (eg: request doesn't fail if expected uuid doesn't match the sent uuid)
🚫 Out of Scope
The text was updated successfully, but these errors were encountered: