Pact FFI Tracking Issue #317
Description
Meta issue for all things Pact FFI interop with Pact-Ruby
📝 Background
One of the strengths of Pact is its specification, allowing anybody to create a new language binding in an interoperable way.
Pact-ruby support up to v2.0 of the pact-specification, and was distributed and used in other languages via travelling ruby.
For a fuller background, please see
For a view of the pact-ruby ecosystem, please see
The main functionality of the Pact-ruby project has been replaced by a core library written in Rust (pact-foundation/pact-reference). This library exposes both command line applications & a foreign function interface which other languages can leverage without the need to re-implement a lot of the logic. The core library helps to maintain parity across the different clients and helps with the adoption of new features.
It has the benefit of supports up to the current Pact V4 specification, which allows end-users to leverage the pact-plugin ecosystem, along with several other quality of life benefits.
For a view of the rust ecosystem, please see
🔍 Overview of the pact-ruby ecosystem
| Project | Purpose | Status |
|---|---|---|
| pact-ruby | core dsl for pact ruby rspec consumers / rack providers | v2 spec + v3 spec message consumers (partial) |
| pact-mock_service | HTTP mock and stub service used in pact-ruby and standalone | replaced by pact-core-mock-server |
| pact-provider-verifier | pact provider verification for running apps (non rack ruby or standalone) | replaced by pact-verifier |
| pact message ruby | provides a consumer message dsl for partial v3 message support | replaced by pact-core-mock-server |
| pact_broker-client | cli to interact with pact broker API | to be replaced by pact-broker-cli |
| pact-ruby-cli | docker collection of ruby gems | in use mainly for pact_broker-client |
| pact-ruby-standalone | standalone collection of ruby gems | in use mainly for pact_broker-client |
| pact-support | shared code for pact gems | in use |
| pact-message-demo | TODO | needs archiving |
| pact-xml | TODO | TODO |
| pact-ruby-e2e-example | TODO | TODO |
| rspec-pact-matchers | TODO | TODO |
| pact-mock-service-docker | TODO | archived |
| pact-provider-proxy | TODO | archived |
| zoo-app | TODO | TODO |
| pact-ruby-standalone-windows-test | TODO | TODO |
| pact-consumer-minitest | TODO | TODO |
🤔 Challenges
- pact-mock_service currently starts a mock server first, and is then loaded up with interactions. When a test is complete, an after hook fires to verify matches were present. Pact FFI uses an approach whereby the an interaction is created by prior starting a mock server. When the consumer has issued a request, mismatches must be checked to ensure the consumer made the correct request. The developer can then perform their unit tests as normal.
- pact-ruby leverages rspec hooks on both the consumer and provider side. on the provider side, it runs through each interaction in the pact, and generates a dynamic rspec test suite on the fly. the pact_ffi verifier is loaded up with sources, and then fired. the user does not have the ability to gain granular access to individual tests
- Pact-ruby uses rack-test to verify Rack based applications, without creating a running endpoint that can be hit externally. pact_ffi requires a running host url, therefore we may need to ask users to start and stop their tests manually. Wonder if we can use lessons from pact-provider-verifier which uses a rack-reverse-proxy (could we start up a proxy app for a url to pass to pact_ffi and pass requests from the proxy to the users rack app
Issues resolved by leveraging the rust core
The rust core may exhibit different behaviour than the current ruby core. In some cases, leveraging the rust core may fix existing defects raised against the pact-ruby projects. Below are a list of some to consider
Validation
- The pact-compatibility-suite should be considered for cross language validation
- Tests should be added to showcase new features