hey all, is been a while since i last looked at pa...
# pact-js
j
hey all, is been a while since i last looked at pactflow, but can someone remind me when you write a consumer test with some data in the query when the producer test verifys this contract it isnt actually creating the data right if it is a post request or something?
m
it will issue the real request at the provider to verify it can handle the request
what the provider does with that request is totally up to it
j
so say it is a graphql mutation it will try to resolve those right?
Matt does that mean it isnt necessarily the case that the mutation will change some state int he database - if the provider test is writen in a certain way?
m
yes (to both)
j
interesting
ah my organisation a while back like 4 or 5 months ago started this contract testing. But they implemented an apollo server that copied over the schema like a mock server to run the priovider tests against. I tried to get them them not to do that, but they kept saying that they couldnt run the provider tests against the real service as they. didnt have an api to seed the provider data base. From what your saying this isnt necessarily the case
m
yeah, that’s a bad idea
j
do you have examples of the provider tests not updating the database but just checking the services are still compatible?
m
Well, all of our examples have to deal with this problem
j
hmm thats so weird we implemented in that way
m
(gtg sorry, on a call!)
j
Just to confirm, as we are testing this out. So basically the provider test wont change the database state for mutations. If we use something like this:
Copy code
describe('API Test', () => {
    const needToBeVerified = ['usernameCheck', 'signup']

    each(needToBeVerified).it('should verify the expectations of %p Graphql', contractName => {
      return new Verifier(createOptions(`apitest-${contractName}-provider`)).verifyProvider().then(output => {
        if (output.includes('Diff')) {
          console.log(output)
          throw new Error(`${contractName} contract test error`)
        }
      })
    })
  })
On the provider side if the consumer test is making a query and if the data is not in the provider side database then this is no problem for pact
m
So basically the provider test wont change the database state for mutations.
When you run a provider test, you need to start up the provider (usually locally). If a consumer needs to perform a mutation, it will send the HTTP request (in this case a graphql query) to the target provider. It is up to you as the provider maintainer to decide if you stub databases or downstream systems, or let it through (highly recommend these are stubbed). See also https://docs.pact.io/provider#stub-calls-to-downstream-systems
Pact is great, but it isn’t magic 😉
j
thanks Matt, one reason the team said they used a mock apollo service is that when they do queries the data isnt int he database ont he provider side
m
That’s what provider states are for
👍 1