Feedback Thread:- Pact PHP v10 alpha FFI

[slt]

Not an issue as such, just want to say I love it. (I'm using 10-alpha3)

It's so much faster and simpler, and I'm looking forward to using some of the newer Pact specification features.

My API tests came across easily without much fuss.

I had to convert my message provider tests from the callbacks to the new format which was a little time-consuming but it makes so much more sense now, rather than having a provider verifier in PHP as a PHPunit test, I'm able to just use the API endpoint and the standalone provider verifier, which makes it more consistent with the non-message verifiers.

My only feedback is maybe the documentation should be updated to spell out the standalone provider verifier should be used along with the API endpoint (and an example), the moment it only talks about the API endpoint and I had to guess the rest, which migrating from the previous version was rather different.

https://github.com/pact-foundation/pact-php/tree/ffi#provider-side-message-validation

Looking forward to the proper v10 release.

[mefellows]

Thanks so much for this kind feedback @slt, being a maintainer can be hard and lonely, but this sort of feedback is the fuel that keeps us going.

(P.S. all credit goes to @tienvx for this work, I'm just here to thank the thanker!)

[tienvx]

Hi @slt

I am not using previous versions so feedback like this is valuable to me.

... I'm able to just use the API endpoint and the standalone provider verifier

My only feedback is maybe the documentation should be updated to spell out the standalone provider verifier should be used along with the API endpoint

I'm curious about the "standalone provider verifier" you are using. Currently I'm aware of 3 ways to verify provider:

1. Ruby's Pact Verifier
2. https://github.com/pact-foundation/pact-provider-verifier
3. Available as CLI and docker image
4. I assume it only support pacts with specification version <= 2. I could be wrong though. Maybe all pact verifier tools are specification-independent
5. Rust's Pact Verifier
6. https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier_cli-v1.0.1
7. Available as CLI
8. It support pacts with any specification version (currently 4)
9. PHP's Pact Verifier
10. https://github.com/pact-foundation/pact-php/tree/ffi#provider-verification
11. Available as a PHPUnit test
12. It support pacts with any specification version (currently 4)

I'm only familiar with #3, and use it in all examples in https://github.com/pact-foundation/pact-php/tree/ffi/example, plus my own private project (just like another test case).

If I understand your comment correctly, I assume you are using #1. And I also assume you are still using specification version 2. If so, can you share your experience about this?

it makes so much more sense now, rather than having a provider verifier in PHP as a PHPunit test

For me, one downside of using #3 is: the PHPUnit test is duplicated again and again in all providers.

[slt]

Thank you @tienvx for all your hard work.

When we initially adopted Pact a year ago we used the Ruby standalone provider, before moving to the Rust standalone in march. We use the pactfoundation/pact-ref-verifier docker image.

To verify the contracts from our PHP service with it, we just set the base_url env var to the pact-messages endpoint we built, it was straight forward.

We have a lot of different projects/microservices in different languages and testing frameworks so the standalone verifier has always appealed to us, & with the provider state endpoints, we can set up any test data we need.

Our existing contracts from Pact PHP v8 were pactSpecification 2.0.0 The ones generated from the 10-alpha3 are now pactSpecification 3.0.0,

Moving to pactSpecification 3.0.0 didn't require any changes for the contracts themselves, the only change I had to do was update our config instances (MockServerConfig, PactMessageConfig).