This type of integration test is useful when dealing with integration points where the provider has a high risk of being volatile (eg, a project under active development).
It can also be useful as a way of verifying mocks used in other tests (the mock is used as the expected and compared against the real).
Decoupling methods are important here and knowing when these should block a deploy.
If both consumer and provider are in a high trust relationship or under the same organization (and can share pipeline), Pact is highly recommended.
- Quick-running, this type of test can be done in a decoupled manner
- The frequency of these tests running can be set based on what is useful
- These tests are intended to break based on your provider’s actions, so you can end up with a broken pipeline you cannot fix. Decoupling methods become very important when dealing with these tests.
- Test only integration points
- Test significantly different cases (eg, a list with 1 item, multiple items, no items, vs invalid request)
- Completely test provider. Just focus on getting example responses your code will need to deal with and highlighting special cases you need to be aware of.
Given state “I have 5 dogs”
When I make a request “How many dogs do I have?”
Then I get response “5 dogs”
State “I have 5 dogs”
Verify request against real api matches expected response