Hi, I am new to Pactflow and doing a POC on contr...
# pactflow
g
Hi, I am new to Pactflow and doing a POC on contract based testing. I want to understand a little more about how pact verification with provider works for certain use cases. Lets say, there is an api like
GET /v1/tickets?user_id=123
which returns list of tickets a user had purchased. Sample response as follows
Copy code
{
    "tickets": [
        { upcoming_ticket1 },
        { upcoming_ticket2 },
        { upcoming_ticket3 },
        { expired_ticket1 },
        { expired_ticket2 }
    ],
    page: 1,
    page_size: 5
}
Now, I want to have following 3 UI test cases. 1. TestUserWithOnlyExpiredTickets 2. TestUserWithBothUpcomingAndTickets 3. TestUserWithOnlyUpcomingTickets While I can create the request/response pairs for these 3 cases that makes the api consumers to test with those contracts, how would the provider validation work for these 3 cases. As I understand from some of the demo videos, the pact broker validates the contract with actual provider. In these 3 examples of contracts, how does the pact broker knows it has to create user with specific state such as the number of tickets with expired/active flag or how do I write the pact to instruct the pact broker to create the users with a given state ? Is there an example that I could refer ?
m
If you’re asking about how state handlers work, all of our examples have them
see howtoexamples
s
m
> As I understand from some of the demo videos, the pact broker validates the contract with actual provider for clarity, for Pact tests the Pact Broker does not do the validation, it brokers the contracts. Pact does the verification for bi-directional contract testing it is where the validation happens.
how does the pact broker knows it has to create user with specific state such as the number of tickets with expired/active flag or how do I write the pact to instruct the pact broker to create the users with a given state
You would use provider states. These are how the consumer states the pre-conditions required for the test to pass. They are written as strings with optional parameters. The provider during verification can optionally use them to setup state on a per-interaction level, to ensure they pass. The consumer shouldn’t know how the provider sets up the state, that is the provider’s implementation detail.