Pact Verifier specifying auto generated id in producer tests

[illumina-icancio]

Is there a way to modify or pass an auto-generated id so that my verifier will be able to find a newly inserted record when it calls the get method?

Example: I have the following API call: GET http://localhost:5000/products/Product-123 and will return
{
"id": "Product-123",
"name": "Some Product Name"
}

In my pact file, I have specified the path as: /products/Product-123 with the specific Id:
{
"description": "A valid GET request for Product",
"providerState": "Products exists",
"request": {
"method": "get",
"path": "/products/Product-123"
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json; charset=utf-8"
},
"body": {
"id": "Product-123",
"name": "Some Product Name"
}
}
}
However, when the provider tests are run, the database is initially empty and I have to stage/set up the data in the provider state. When records are created/inserted in the database, the Ids are auto-generated and there’s no way to match what is specified in the pact file. So in my tests, the id generated from my data setup will have a value different from what is specified in my pact file.

When I run my tests on the provider side, the request I specified in my pact file will return a 404 because it does not exist. Is there a support/workaround for this where I can replace the id or the path? If yes, can someone point me to an example or a documentation please.

Appreciate any help. Thank you!

[vikasillumina]

@neilcampbell This seems like a very commonly used feature that my team also needs.
So basically if I am understanding the question above correctly, we don't have a way to pass in the id in the contract json file that Producer will run on its own side where id is autogenerated. Any examples how to by pass this issue will be great.

[neilcampbell]

@igsunga @vikasillumina Instead of using provider state to insert data into a database, can you create a fake/stub database layer (giving you full data control) that get injected (via IoC or something) when running the pact provider verification? This is how I have tackled it in the past, and it typically makes testing a lot faster and more deterministic.

[vikasillumina]

@neilcampbell Thanks for your quick response. Actually the problem is not with staging the data. The problem I am facing is with running the Provider side test based on the interaction provided by the consumer pact file.

The consumer pact is saying if we follow the above example, when consumer A consumes provider service B using:
GET/products/Product-123
we will get a body with:
"id": "Product-123", "name": "Some Product Name"

where product-123 is an uniquely generated primary key, but we can't predict this key.
So we were hoping if there is a way when provider pact tests are run if we can modify the id on run time with the actual id returned by the newly staged data.

I saw this post :
https://stackoverflow.com/questions/46252231/pact-how-to-test-a-rest-get-with-automatically-generated-id-in-the-url
which mentions this :
https://github.com/DiUS/pact-jvm/blob/master/pact-jvm-provider-junit/README.md#modifying-the-requests-before-they-are-sent-version-323245
does Pact-net supports this?

Only workaround I can think of is Consumer A and Producer B sit together and identify the interaction and the required data on the provider side is pre-populated and made sure that this data will always be there and wouldn't need to be created again. This way the primary key will be known ahead of time and then consumer A write their pact using the key.
Don't quite like this since there is overhead of maintaining the state of the data which could be tricky to set up, especially on short lived environments. Sometime there is complexity around staging certain type of data to. Also the data would need to be maintained with changes done to the api contract.
But do you have any other suggestions?

[daveboyle1]

i think matchers may solve your problem. match the type (e.g. int) for your id rather than matching the exact value. e.g. product-123. https://docs.pact.io/getting_started/matching

[daveboyle1]

spec 2.0 introduced matchers https://github.com/pact-foundation/pact-specification/tree/version-2

[neilcampbell]

@vikasillumina This to me is 100% a data issue. One of the big problems with using staging environments is keeping the data in a deterministic state. If you have the right layers in your code you should be able to isolate and fake/stub your external dependencies (like a DB) and then your contract tests don't need to run on a staging environment at all, and don't require a running database. I know this option isn't easy, but I believe it is the most robust.

Alternatively you could use some middleware in your running provider to intercept request and mutate them to values you know are in the DB. I'd generally advise against this where possible.

@daveboyle1 Unfortunately matchers won't work, as a sample is recorded when creating the consumer test, and it's that sample which is sent to the provider during verification. If the provider returns a 404 for that request, the matching will fail.

[daveboyle1]

@neilcampbell, yeah true. need to have that ID setup in an in memory DB/fake/stubbed DB layer so that your getting back the 200. Sorry, I was mixing up with a post where you may return a created ID, where you wouldn't know the ID that was going to get created. my bad, rushed response.

@vikasillumina we used the middleware approach where you setup some provider data (literally insert product-123 for the test). We used an in memory sql lite DB. that worked pretty well if your using something like sql server in real life. Definitely create and tear down your data per test if you can. Extra effort, but well worth it.

[neilcampbell]

@daveboyle1 Approach sounds like a great idea if possible.
Just to be clear the middleware approach he is suggesting is using a provider state middleware (similar to what is in the repo sample), which would be much better than using a middleware to change requests and responses coming in and out (the not recommended alternative I suggested).

[daveboyle1]

yep. definitely wouldn't want to be changing requests and responses coming in and out.

[vikasillumina]

Thanks @daveboyle1 @neilcampbell for your all helpful comments and directions. This is really helpful and I may already have something that I think I can use. I am referring the Component Testing so instead of invoking the actual local CI environment we will spin up the Producer API with in memory db which we can control more easily.

[daveboyle1]

thats pretty much how we did it. spin up a kestrel server and create a TestStartup that inherits from Startup and use that to override our database setup with an in-memory version. Never used any real life servers. Also, .net core's TestServer class wont work, you'll need to spin up a proper Kestrel server. (if your using .net core). TestServer is good for normal integration tests, but need proper network connections for Pact. hope that helps a bit if your using .net core.

[illumina-icancio]

Thank you all for your help! I will do as explained, set up the data instead and use those for the tests.

Closing this issue.

[nithinacv]

Is this limitation still valid? Is this something that can be achieved using Provider States? I am new to Pact and not sure when Pact Provider States became available in the development timeline.