[Best Practices] Setting states on provider can be...
# pactflow-ama
j
[Best Practices] Setting states on provider can be a nightmare for a provider to manage when overused by consumers. How to manage setting provider states at scale?
m
I am very interested in this question. It is a question that my team and I started to hit as well. We began to think about having the providers share the states usually used by different consumers so we don’t end up in a situation where we have tons of varying state names with the same end goal. We still have to put this idea to proof. Do you have something in mind?
j
From my experience I strongly suggest: 1. Avoid states a. at first try use loose matching 2. Reusing states a. provider manages states it supports, it's his responsibility to enable consumers to fit new interactions into existing states. 3. Black Boxed state definitions a. Set states using intention, not SQL inserts. b. Consumer should say:
set state for a price discount for itemId: 123
, instead of
insert item with id 123, insert price for it, insert VIP user, insert VIP discount configuration, ...
4. Treat states as part of the contract a. list of states and their configuration is a kind of public agreement between provider and consumer, where it is provider who owns it
m
Sorry for the delay, it’s holiday season in Aus where many of the maintainers are so we’re a bit behind on some of these q’s.
This video might be helpful to watch: https://docs.pact.io/consumer#watch-a-video-writing-good-consumer-tests. i’m pretty sure it covers states a bit