Hi This is pavanraj from atlassian, we have use-ca...
# generalp
Pavanraj Ramisetty
05/07/2025, 9:55 PMHi This is pavanraj from atlassian, we have use-case of asynchronous api,
1. The api accepts the order and responds with 202.
2. Consumer polls on get order, based on the type of order placed, there will be fields set in the response.
What is the recommendation for writing contract tests ?
How do i get the confidence that any modification in order processing flow would ensure fields are populated as expected for the use-case ?
b
Boris
05/08/2025, 6:05 AMNormal consumer-driven contract testing would make this several separate interaction (since each interactions is stateless).
1. Initiate the order (1 test per significant scenario, e.g. 202 is the success, you might also have 4XX range rejections, etc)
2. Request the status of an in-progress order
3. Request the status of a completed order
4. And then other unhappy paths, like requesting the status of an invalid order number (404), etc.
m
Matt (pactflow.io / pact-js / pact-go)
05/08/2025, 9:40 AM
Yep! Thanks Andras (I’m still working on that tee for you btw - I didn’t get to HQ this week!)
p
Pavanraj Ramisetty
05/09/2025, 5:31 AMWhat is your recommendation on setting the pre-state for get-order based on output of integration test ?
m
Matt (pactflow.io / pact-js / pact-go)
05/09/2025, 5:43 AM
It would be something like
GIVEN “an order has been successfully placed” <- pre state
WHEN “a request to fetch the order status” <- description
THEN “I get a HTTP 200…with body…etc.” <- assertions
b
Boris
05/09/2025, 6:02 AMI think we might be interpreting the question differently 😅 because Pact interactions are stateless (i.e. there is no state maintained between interactions, you can't chain them, etc), the pre-state will not be based on the output of an integration test.
So, something like
• given: an in-progress order
• when: the status is of the order is checked
• then: it yields in-progress metadata
(Which is basically the same outcome, but described slightly differently)
Boris
05/09/2025, 6:11 AMThe strategy for determining the concrete data will depend on how you stub the data in your tests, and how strict/loose you want the interaction to be. For example, the state "an in-progress order" may stub the data for all requested orders, so no matter what ID is provided, you get the same response (provided you request the correct parent resource). Or you could have an agreement between the teams of the values to expect for each ID, e.g. 1 is in-progress, 2 is finished, 3 doesn't exist, etc.