Gunaraj Shanmugam
10/23/2023, 9:08 PMGET /v1/tickets?user_id=123 which returns list of tickets a user had purchased. Sample response as follows
{
"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 ?Matt (pactflow.io / pact-js / pact-go)
Matt (pactflow.io / pact-js / pact-go)
Slackbot
10/23/2023, 11:54 PMMatt (pactflow.io / pact-js / pact-go)
Matt (pactflow.io / pact-js / pact-go)
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 stateYou 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.