Do people generally use the pact verifier cli in o...
# pact-beam
j
Do people generally use the pact verifier cli in order to verify their pacts? If so, how does that work with seeding data into the application?
j
It certainly is possible to use the FFI as well. The available methods can be found here. I'm not what you mean though by 'seeding data'. Pacts are consumer driven, so the consumer side would create the contract. Then on the verifier side, you point Pact to the contracts (by way of either files or a broker), and Pact will replay these contracts against the provider to verify.
👍 1
j
Right. But if I wanted to write a tests that searches for something, that something needs to exist within the producer application. Given this Erlang library, I can write something like this that defines that some state needs to live on the producer side. If I am using the verifier cli, I can't really see how I am supposed to get this data. The library tests for this project use the verifier via docker in the tests. But I am not really seeing how that creates the data required in order to make the test pass. Presumably if there was no data in the database (or wherever this data is retrieved), the search would fail and you would return something other than the expected searched for item.
m
I vaguely remember doing something similar with the CLI tool. I want to say it was roughly like this https://docs.pact.io/implementation_guides/rust/pact_verifier_cli#state-change-requests where it can make API calls to setup state though I remember having to setup handlers for various state scenarios to manually setup the data on the provider side. Don't know if the Rust thing I'm linking is exactly what I was using at the time though. This was many years ago.
☝️ 1
j
Okay. Test specific routes might be okay.
👍 1
p
@Justin Wood the provider has to implement the
/pactStateChange
api and the “pact mock consumer” which is the pact verifier cli will call this api with the the below payload:
Copy code
{
"state": GivenInTheConsumerPact,
"params": StateJSON
}
although in the new PR in pact_erlang I introduced a wrapper over the pact ffi’s verifier functionality to verify the provider without the need of docker and the pact-verifier-cli tool
j
That would be really helpful. Thank you for getting that implemented!
j
Yeah, to echo and hopefully clarify things a bit. As you have found already, the consumer can specify provider states such as
given user 1 exists
. On the provider side, Pact allows for the state to be changed through a callback. The callback more specifically is a dedicated API endpoint available during testing which is designed to alter the provider's internal state (e.g.
/_test/callback
). In order to avoid the need to spin up databases and actually mutate other services, it is also best practice to mock sources of data external to the provider. There are examples of this setup on various languages, for example Python, JavaScript.
j
Thank you for the information!