Hello All, I have some questions. I am working...
# general
p
Hello All, I have some questions. I am working on setting contract tests for a GraphQL service (provider) using Pact. The provider is a Ruby on Rails app, the consumer is JavaScript. The JS version of Pact was wrappers for creating GraphQL interactions but the Ruby version does not. 1. For the provider (Ruby) do I create state handlers that return the correct GraphQL. where the objects are loaded from say a file or 2. Do I have to: • Have the actual provider running; and • Have to seed the DB with the data elements the tests need Item 2 above being more complicated I am guessing the answer is implement the provider verification as in item 1 above, is that correct?
m
If you did (1), how would you be confident your GraphQL provider actually works?
The point of provider verification isn’t to make Pact tests pass, but to ensure your provider actually works
(so the answer is 2)
p
The point of provider verification isn’t to make Pact tests pass, but to ensure your provider actually works
Exactly! and thank you for replying. After saying the approach should be (1.) got me thinking what’s the point of having hard-coded responses? What if the schema changes and developers fail to update the hard-coded responses? Then will you please explain what’s the use of state handlers (provider states)? Do the state handlers query the db for the data that was seeded just for the tests? How do we link a state handler for say ‘state 1’ with the query that returns the values in the db for ‘state 1’?
m
p
i have also have read https://docs.pact.io/implementation_guides/ruby/provider_states and https://docs.pact.io/getting_started/provider_states#:~:text=Provider%20states%20allow%20you%20to,matches%20what%20the%20consumer%20expects and https://github.com/pact-foundation/pact-provider-verifier#api-with-provider-states it is finally coming into focus! (I think) The expected provider state will be passed to the provider via the/from the Pact file that the consumer created. The endpoint to create the data, tries to create the data and return an error if it doesn’t recognize the state or even if it recognizes it but the “shape” of the request does not match the current schema in the db of what Pact is passing.
🙌 1
m
It needn’t be writing to a DB, but that’s an option for sure
The idea is that your consumer can signal to your provider somehow that it needs to be in a given state, for a test to work. Just like the
given
in your TDD tests, just at an API testing level. The given represents some arbitrary, abstract state. How you get into that state is up to your provider (implementation detail)
p
this is great info. thank you
🙌 1