Right now the plan is to: 1. Finish gRPC / protobufs plugins (work in progress now) 2. Improve the documentation and visibility of the plugin ecosystem - make examples, tutorials, workshops etc. so that maintainers and contributors can use and create them 3. Get the rust core into all key languages (JVM, JS, Golang, .NET, Python) 4. Add plugin support to all key languages Ruby is not on that list, but after (2) it could be done with community support

Sounds great, thanks Matt!

If you’re interested in picking up (3) for Ruby, there’s nothing stopping you now. See #libpact_ffi-users if you’d like to get involved! (and also probably pop your hand up in #pact-ruby)

Thanks Matt, will look into it

You don’t happen to have a rough ETA on GRPC for pact-go, do you? 🙏

Hey Cody! It’s in a branch, let me get it merged and you can have a play with the next beta release.

Momma always said “just ask nicely, you never know” 😂 Thanks!

What do you plan on testing, btw? If you can give us some idea of your use case that would be great to know

Yeah, we have an intern (Runlin) digging into all of this right now. I think day 2 of his internship he had a pact broker running (locally) already and has been writing tests on the HTTP side of the house. Happy to setup a zoom at some point to chat through everything. It definitely feels like right now we’re seeing what all ways we can abuse your tools 😂 We have a bunch of weird requirements we’re trying to balance that leads use quite a few of your tools together. • Ex: bidirectional contract testing looks pretty exciting, and I assume it’ll work better than the swagger-mock-validator we use today — unless that’s what is used under the hood. But we’re using the OSS broker, so this isn’t supported (yet?). • Using the wiremock-pact-generator to try to reduce the work on consumer teams. Runlin already has a POC using this too. But then we expect we’ll want BDCT to validate these much quicker, since my understanding is that a bunch of duplicative tests like we’d generate would be too slow to validate normally. But trying to see if this theory is true • And now we get to add GRPC into the mix, because a lot of our API calls are over GRPC and “faking” our contracts using grpcgateway seems… fallible.

Ex: bidirectional contract testing looks pretty exciting, and I assume it’ll work better than the swagger-mock-validator we use today — unless that’s what is used under the hood. But we’re using the OSS broker, so this isn’t supported (yet?).

It is, but we have customised it to address a few things.

Yeah, I heard from a couple of our teams that tested that it has… issues. 🙈

Using the wiremock-pact-generator to try to reduce the work on consumer teams. Runlin already has a POC using this too. But then we expect we’ll want BDCT to validate these much quicker, since my understanding is that a bunch of duplicative tests like we’d generate would be too slow to validate normally. But trying to see if this theory is true

💯 do not use the standard pact verification here. It won’t just be duplicative, but likely very flakey and hard for the provider team to verify reliably.

Interesting. What would make them flakey? I assumed the main challenge on the providers (besides speed) would be handling a million different provider states.

Interesting. What would make them flakey? I assumed the main challenge on the providers (besides speed) would be handling a million different provider states.

yes, that’s one. Because the wiremock pact generator doesn’t care for states (unless I’m mistaken), the provider won’t know how to deal with all of the scenarios.

wiremock itself has pretty solid state/scenario support, but yeah no idea how that translates into the pact.json

to my knowledge it doesn’t. But that would be an obvious addition to the tool