surpher / surpher/PactSwift

Support matchers and example generators in requests

Open
#113 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement help wanted v2.x.x
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.