Hi all (sorry for a long message) We’re using <Pac...
# general
j
Hi all (sorry for a long message) We’re using Pact.Net with the following setup: 1. One system consisting of: ◦ Client-side UI ◦ Web API BFF ◦ The BFF has a couple of GraphQL dependencies downstream (these are our Pact providers). 2. We run UI tests against the BFF and use Pact to mock the downstream GraphQL providers (Pact.Net consumer tests generate the contracts). 3. We then run provider verification against these contracts for the GraphQL services. Our challenge is around _IDs_: • The UI tests use static IDs in GraphQL queries (e.g.
room(id: "123")
), and these IDs are recorded in the pact. • When we run provider verification, those IDs usually don’t exist in the provider’s real database. • We have a provider state setup tool that runs mutations to create test data, but the provider uses identity/auto-generated IDs, so the IDs returned from setup don’t match the hardcoded IDs in the contract. Conceptually, we’d like to: 1. In provider state: run a mutation to create test data and let the provider assign an ID. 2. In verification: use the ID returned from setup in the GraphQL request for that interaction. Questions: 1. Is there any supported way in Pact for provider state output (e.g. a newly created ID) to influence or substitute into the request during provider verification? 2. If not, what’s the recommended way to handle this pattern of: ◦ Consumer/UI tests that send static/example IDs ◦ Providers that rely on auto-generated identity columns?
m
1. Is there any supported way in Pact for provider state output (e.g. a newly created ID) to influence or substitute into the request during provider verification?
I believe Pact .NET doesn’t currently support that, see https://github.com/pact-foundation/pact-net/issues/385
1. If not, what’s the recommended way to handle this pattern of:
◦ Consumer/UI tests that send static/example IDs
◦ Providers that rely on auto-generated identity columns?
Unfortunately, we usually expect to be able to fully control the provider side during verification - usually this is achievable through stubbing or other unit-test level interventions.
j
Thanks for your response. By stubbing, do you mean stub the provider's database to return whatever ID is needed in the test?
m
That's an option, or even the database layer if that's easily and safely done
j
Hi Matt, is there any plan to make
valueFromProviderState
supported in Pact.Net. Do I understand correctly that this feature is already supported by the Pact provider verification tool, but it's just Pact.Net that cannot generate it in Pact json file?
m
I’d like to see it in the Pact .NET package. I’d suggest voting on the issue above. It’s supported in the core, it just needs to be exposed in the Pact .NET interface. If you were willing to contribute, that would be great. The suggestion on the above feature request is to put forward an API proposal before implementation.
j
I found this PR but it seems to be for Pact spec v3. https://github.com/pact-foundation/pact-net/pull/380
m
yeah, looks like it probably needs to be ported against the latest .NET code base
j
Thanks Matt, contributing to Pact.Net might be an option. I will give it a thought and come back later.
🙏 1