search

Kuper-Tech / sbmt-pact

Ruby gem for simplified Pact testing between microservices, supporting the latest Pact specifications and multiple transport protocols
MIT License
46 stars 1 forks source link

The path to Pact-Ruby #1

Open YOU54F opened 1 day ago

YOU54F commented 1 day ago

Hello team!

Firstly, awesome work on the library, great to see someone able to pick up on the pact-ruby-ffi wrapper library I created as a playtime hack with Ruby. Build it and they will come :)

We would love to try and integrate your changes into Pact-Ruby to enable users in the Ruby ecosystem, to leverage the new Rust core shared features, and to allow a migration path for the existing tests that have already been written, and the Pact-Ruby project has now been around for over 10 years.

Overview of ecosystem

The current Pact ruby ecosystem looks something like this

https://docs.pact.io/diagrams/ecosystem#ruby-goldberg-machine

Once we migrate over to the pact-ruby-ffi project completely, there is be no direct consumers of the pact-ruby-standalone project, meaning we can deprecate several of the libraries

leaving only the following as required.

Questions

So that leaves me with a couple of questions

  1. Would you be open to incorporating these changes into the Pact-Ruby project?
  2. If yes to above, would your team like to be involved in that work?

Musings

I've taken a look at the library so far and have been working across this branch in my fork

A few things I have noticed so far, and this isn't critical at all. I've addressed most of these so far

  1. The project appears to use rails in a few places, pact-ruby has traditionally targeted Rack based apps on the verifier side with Rack-Test, and as such the users would be expected to pass their Rack app into the provider verifier, or read automatically from a config.ru file. i. Only use rails methods if Rails is defined ii. need alternatives for deep_dup / blank if we don't want end users to have to require activesupport
  2. Consumer side - Pact handles are created every interaction. This stops a user from being able to setup multiple expected interactions before invoking the mock server. In the case of the Pact Broker client tests, these use HAL relations, so a method under test calls 2 endpoints, an index, and follows the hal resource. Both interactions need to take fulfilled for the function to succeed. i. Create pact_handle on init of new pact. Reuse pact_handle on new interaction creation if it exists. Allow user to call execute on the pact level as well as the interaction level as current behaviour.
  3. Consumer side - Default ports are fixed i. Setting port to 0, will allow the pact core to assign a random port. ii. the returned value from create_mock_server_for_transport, is the assigned port number iii. nice convenience to return the constructed url of the mock server, back to the end user, in the execute blocks.
  4. Provider side - Consumer version selectors - the sbmt-pact sends default consumer version selectors, and filters them based on a user provided consumer name i. . This isn't required, if no consumer version selectors are supplied, when the broker_source_with_selectors method is called, the Pact Broker will return a default set of selectors. ii. Therefore in order to use the recommend setup, users shouldn't need to provide any selectors, and the framework shouldn't need default any for the user.
  5. Provider side filtering in done automagically based on meta in the pact description to denote which type i. This stops users from being able to verify all interactions in a pact, and will stop users from being able to publish verification results (as the filter will remove some interactions, meaning the pact broker cannot be certain that the pact is fully verified or not) ii. we shouldn't be opinionated on the description of the interaction, in order to set which pacts will be returned, as we may be able that constraint to the pacts generated from sbmt-pact's consumer side. iii. I'm not sure yet how we can validate a mixed pact, that contains http/ async & sync message interactions in a single test run, as V4 pact spec allows for mixed interactions and we would need to know all interactions were validated to publish a result.
  6. Provider side pact sources i. pact ffi supports loading multiple sources, but it doesn't make sense for an end user. They should verify one source, a file, dir, url or dynamically fetched. ii. verification by url isn't supported iii. several options relating to provider side options publishing were missing
  7. Provider states i. the ability to scope provider states by provider name would be good ii. the ability to import provider states from another file

It would be nice to retain parity with pact-ruby in a few places. I am implementing sbmt-pact from my fork, against pact_broker (as a provider) and pact_broker-client (as a consumer)

Demos

Adapted from existing pact-ruby demo codebases and real world production pact-foundation apps

bibendi commented 4 hours ago

Hi Yousaf,

Thank you for reaching out and for your thoughtful feedback on sbmt-pact. We appreciate the time and effort you’ve put into exploring our gem and sharing your observations. It’s clear that you have a deep understanding of the Pact ecosystem, and your insights are highly valuable.

Your proposal to integrate our features into pact-ruby is interesting, and we’re grateful for the invitation to collaborate. However, at this time, our team is fully focused on internal priorities that have already been set for the upcoming quarter. Over the past two quarters, we’ve invested significant effort into developing and refining our Pact-related tooling, and unfortunately, we’re not in a position to contribute to open-source initiatives right now.

That said, we’ve reviewed your feedback and found several excellent suggestions for improving sbmt-pact. While we can’t commit to addressing all of them immediately, we’ll be discussing which of these improvements we can prioritize during our team’s planning session in December. Your observations are incredibly helpful, and we appreciate you taking the time to share them.

We’re confident that your work will continue to strengthen Pact, and we look forward to seeing the progress you make with pact-ruby.