Support matchers and example generators in requests
Nobody has claimed this yet.
- Dominant language
- Swift
- Stars
- 56
- Forks
- 21
- PR merge metrics
- No merged PRs in 30d
Description
🗣 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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start from the v2.0.0 branch and the request expectation path shown by withRequest and jsonBody, including the matcher and example-generator forms in the issue. Trace how these expectations become a Pact contract and are verified; done means both are represented in the contract and generated request values do not cause interaction verification to fail.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100