does anyone know how to handle provider states for running provider tests against the actual api? We're using Docker to run it as its own instance against a test db before running the tests.

Provider states require a test-only endpoint to be available. So if you’re running it in docker, you’d need to make sure that endpoint is available

Can you run it without provider states? How do people normally test against the actual provider?

It’s not a recommended/common scenario.

so how would it actually test the provider for changes? If you're just testing an endpoint you created for the tests, you're not actually testing anything but a test

The endpoint is the provider state handler endpoint, not a fake version of your API. You definitely need to test your real API (otherwise as you say, it’s not very useful)

I haven't seen any examples online of anything involving provider states that wasn't fake, unfortunately

can you point to an example? Perhaps I can then make sure it’s not misleading

here's one example: https://github.com/DiUS/pact-workshop-dotnet-core-v3/blob/master/Provider/tests/Middleware/ProviderStateMiddleware.cs

So what’s fake about it? What happens is this: 1. Pact reads the pact file 2. It then loops through the interactions 3. For each interaction, it executes all provider states (i.e. test preconditions) a. This is where a request to the provider state endpoint is called to setup the provider into a state for the real request (to the actual endpoint) to work correctly. e.g. ensuring a user is in the database for a GET /users/:id 200 or ensuring a user is not in the database for a GET /users/:id 404 scenario) 4. The real request to the actual endpoint is sent 5. Pact checks the response

we have a separate call to seed data that is being done prior to this, I'm guessing that typically that's done by the provider state?

correct. What you’re suggesting is reasonable though if it covers all of the states you need

do the states ordinarily line up with the pact or is it just a standard add/remove data?

the concept of a state is quite abstract - it could be configuring a mock, seeding data into a database etc. Whatever is required to get the system into the state needed for the test.

does the provider state endpoint have to be on the provider or can it exist separately?

does the provider state endpoint have to be on the provider or can it exist separately?

great question - the answer is that it doesn’t matter. It could be a separate test-only API that also can write to the underlying DB (if that’s the state that needs manipulation). Obviously, in-memory stubbing wouldn’t be effective this way, but I think you get the point

gotcha, thanks for all of your help! you just spared me from a hefty migraine 🙂

No worries! I’ve got it on my list to update the docs page on provider states. This detail needs to be there Hopefully you can sleep easy now 😉