You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've got a provider with an entry point function. It fetches data in a complicated way, but that complication is all bottled up in a function called retrieve_data, which I import from another library and run in the provider's main.
I've got a pact, and I want to verify that against the provider. But if I outright run it against the provider, the provider goes and fetches real data with real retrieve_data calls. I don't really want the test to rely on the mechanism underpinning that call, because then it becomes more brittle. I want to instead read test data.
Due to how complicated retrieve_data is, I can't very easily stand up a different location for it to fetch from and fill that place with the test data. Instead the simpler and preferred way is to just mock this function altogether so the queries never have to be made. The provider doesn't need to know the difference.
I've come across provider_states and many mentionings and explanations that make it seem like I'm facing a common problem and that there should be an established solution. "Provider states allow you to set up data on the provider by injecting it straight into the data source before the interaction is run, so that it can make a response that matches what the consumer expects." -pact docs. But as yet I don't really understand how to apply this to my case, i.e. to reassign the retrieve_data function or otherwise mock it.
Given the test requires a live, running endpoint, I'm not sure mocking of any variety is possible. Right now I've gotten around this by inserting a monkey patch, triggered by the presence of a particular header, that sets retrieve_data = mock_retrieve_data, where the latter is a function defined below my provider's main that specifically fetches the test data. This strikes me as a hack, but possibly the only viable hack for changing the behavior of an actually-deployed provider.
Is there a way to set up a provider's state so as to return the answer the consumer expects? The documentation hints that the answer should be yes, but I don't yet see it.
The text was updated successfully, but these errors were encountered:
I've got a provider with an entry point function. It fetches data in a complicated way, but that complication is all bottled up in a function called
retrieve_data
, which I import from another library and run in the provider's main.I've got a pact, and I want to verify that against the provider. But if I outright run it against the provider, the provider goes and fetches real data with real
retrieve_data
calls. I don't really want the test to rely on the mechanism underpinning that call, because then it becomes more brittle. I want to instead read test data.Due to how complicated
retrieve_data
is, I can't very easily stand up a different location for it to fetch from and fill that place with the test data. Instead the simpler and preferred way is to just mock this function altogether so the queries never have to be made. The provider doesn't need to know the difference.I've come across
provider_states
and many mentionings and explanations that make it seem like I'm facing a common problem and that there should be an established solution. "Provider states allow you to set up data on the provider by injecting it straight into the data source before the interaction is run, so that it can make a response that matches what the consumer expects." -pact docs. But as yet I don't really understand how to apply this to my case, i.e. to reassign theretrieve_data
function or otherwise mock it.Given the test requires a live, running endpoint, I'm not sure mocking of any variety is possible. Right now I've gotten around this by inserting a monkey patch, triggered by the presence of a particular header, that sets
retrieve_data = mock_retrieve_data
, where the latter is a function defined below my provider's main that specifically fetches the test data. This strikes me as a hack, but possibly the only viable hack for changing the behavior of an actually-deployed provider.Is there a way to set up a provider's state so as to return the answer the consumer expects? The documentation hints that the answer should be yes, but I don't yet see it.
The text was updated successfully, but these errors were encountered: