Support matchers and example generators in requests
#113 geöffnet am 26. Juli 2023
Repository-Metriken
- Stars
- (55 Stars)
- PR-Merge-Metriken
- (PR-Metriken ausstehend)
Beschreibung
🗣 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.
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.
📝 Notes
Branch off of https://github.com/surpher/PactSwift/tree/feat/v2.0.0
💬 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
class SomePactTest: PactTestCase {
class SomePactTest: PactTestCase {
func testAnInteraction() async throws {
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 request
try 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 in
try 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
N/A