I was looking into the provider state. So is it ju...
# pact-js
j
I was looking into the provider state. So is it just a case of having an in memory database (or even just hardcoding it)for example in the provider test. Using the same data that the consumer request expects and to include that in the opts:
Copy code
const opts = {
  ...
  stateHandlers: {
    [null]: () => {
      // This is the "default" state handler, when no state is given
    }
    "Has no animals": () => {
      animalRepository.clear()
      return Promise.resolve(`Animals removed from the db`)
    },
    "Has some animals": () => {
      importData()
      return Promise.resolve(`Animals added to the db`)
    },
    "Has an animal with ID 1": () => {
      importData()
      return Promise.resolve(`Animals added to the db`)
    }
  }
}

return new Verifier(opts).verifyProvider().then(...)
so like in the above example. If the consumer is expecting in the request it sends an id, and name and expects the id to be 1. Can i just hardcode the data as something like this:
Copy code
{
  "id": 1,
  "name": "dog"
}
b
This family of questions has been coming up a bit recently, I wonder if there's any docs written about it 🤔
Really, it depends where you want to cut the provider for testing. And it's entirely up to you.
I prefer to stub responses about a-layer-and-a-half into my provider, to make sure the requests & responses execute a hint of logic (parsing is the minimum).
You can also stub the entire database, outside the provider. That gives a bigger footprint (less isolation), but might be easier to do, depending on your architecture.
With a clean architecture, I stub either the domain layer, or the use case layer, and provide that through DI.
j
Hey Boris thanks for the response. I just have trouble navigating the documentation for pact
b
Makes sense, there's a chance it's not clearly structured in the docs, but the conversation happens a bunch in Slack 😅