Skip to main content

32 posts tagged with "pact"

View All Tags

· 10 min read

⏳ And just like that, 2023 draws near​

We at the Pact team love nothing more than making microservices testing easier, our community and churning out the code. This year has been no exception. As many of you have wrapped up for your christmas break, we thought we would take some time to reflect on the year and the communities achievements.

Pact Open Source Community Survey​

Our new survey is now open! The purpose of this survey is a pulse check on the community. In order to serve you in the best possible way, we'd love to understand how you use Pact and engage in our ecosystem. If you have contributed to any Pact Open Source projects or have engaged with Pact social media and Slack chats, you are welcome to share us your thoughts! The data collected in this survey is anonymous. We intend to use the data to better serve you and to promote the Pact community. Complete the survey here.

Brought to Life through Visualizations​

Earlier in the year we mentioned we rolled out Orbit.love to help us track activities across the Pact Foundation's many open doors.

I would login into GitHub, Slack, YouTube, Slack Overflow, Twitter, check my emails, all before I could get down to any work. I imagine the story is much the same for our maintainers, when they get that precious free time to code, it can be exhausting. Orbit gives me a single view I can go to every day, and see who is posting asking for help, or where the activity is, so I can come jump in a help out.

We’re still in the process of determining the most effective usage and views of the data, in a wider context rather than just helping us on the day to day. We are thinking about ways we can expose the dataset (as it’s all publicly available information from GitHub), so that you can tell us what you make of it. Think of it as an interactive state of open-source survey if you will! The good news is that we’ll be doing so together with our friends over at the Cucumber and Swagger communities. We even hope to extend it over the SmartBear GitHub account too.

Pact community engagement in 2022​

Community growth in 2022​

We saw over 3,000 of you interacting with us via our open source channels, and introduced 2.7k more into the fold.

The 2022 community heroes.​

Thank you for participating in the Pact community, we couldn’t do it without you.

We really couldn't resist taking a look at what organizations are using (and we hope loving) Pact. The list below is ordered by organization employee count.

We're a small team at Pact, so we also rely and appreciate contributions by teams and individuals leveraging Pact. Below is a list of organizations ordered by the active members using Pact who have interacted with our public repos. In most cases, these are individual people, or small teams often giving back improvements to the Pact framework from time out in the field. Why not read some of their testimonials and case studies here and add one of your own 🥰

Community growth since 2013​

We looked back on the history as Pact, as we near 10 years, over 12 thousand of you have followed along.

I wrote an interactive history lesson of Pact which you can check out here

Big innovations: the Pact Plugin Framework​

We were pleased to launch the Pact Plugin Framework to the masses. As with all our major initiatives, it is true to our open source roots and we hope that unlock new capabilities to a community of builders.

Our first plugin provides support for testing gRPC with Pact, and Pacts core, built in Rust, provides a Foreign Function Interface, unlocking Pact’s capabilities in supporting languages.We look forward to 2023 and the introduction of Pact’s feature-set to a few more languages, some of which are waiting to be built.

Hopefully by you!

In the meantime, why not get powered by Pact plugins and create your own?

Find out how to get started

Supporters of Pact​

Pact’s biggest sponsor got even bigger this year.

SbHeartPact

Pact arose while PactFlow's Co-Founders Beth Skurrie, Ron Holshausen and Matt Fellows were employed by Australian technology consultancy, DiUS, supporting companies of all sizes to transition to cloud-native application development and to accelerate their digital initiatives.

PactFlow is now part of a much wider quality initiative after being acquired by SmartBear. We care so much for OSS and are so pleased that SmartBear has a strong and demonstrated commitment to OSS — as proven through the support and scale of Cucumber and Swagger. Through our partnership, we will be able to take contract testing to new heights and help deliver key milestones in Pact’s OSS roadmap, and bring closer alignments between our now larger family of open source tools, and smooth pathways between our open source and commercial tools. Providing you a seamless, and wonderful experience, whichever tool you are using.

We are always on the look-out for new contributors, across any of our languages, and if you have interest or have used Swagger, Cucumber or BDD principles in the past, we would love to hear from you. Drop me a note in Slack.

We would also love to wish our DiUS family thanks for all the support, and helping us reach bigger heights, and ultimately help more people. We'll slip an extra shrimp on the barbie for you.

What's in store for Pact in 2023?​

With a successful 2022 under our belts, I am so excited for what 2023 has instore! You can check out Canny, our public feature board for the latest run down on upcoming initiatives.

If you feel like something is missing, why not request it, or come talk to us in our Slack?

Big call outs to get excited about​

  • Pact Plugin ecosystem – we look forward to helping the community build plugins for the most requested content and transport types
  • V4 + Plugin support in all Pact foundation supported languages
  • Support networks provided to help the community build new plugins, and language implementations
  • Improved governance and project planning
    • The Pact project is depended on, by millions. In order to improve the quality of life for maintainers and contributors, we would like to bring some best practice open source engineers principles to the Pact project, to help it evolve in a vendor neutral fashion, and live for many years for come.
  • Revised documentation, training materials and examples
    • We are on a journey to help not only simplify the adoption of contract testing, but with SmartBear’s support, to help provide you patterns and techniques to building quality, scalable software, that moves as quickly as your customers do. We would love your support in helping to smooth the path.
  • Help us design real-world example applications, that we can use to demonstrate not just Pact, but other testing tools, to show you can pick n mix your way to success.
  • More community events
    • Pact's 10th Birthday Bash
    • Local Pact community events
    • SmartBear Dev Rels’ Celebration of open source
    • Hackathons
    • Code Alongs
    • Summer of Source
    • CukenFest - A BDD Conference
    • Pact + Swagger + Cucumber meetups

Pact Almanac 2022​

I always love the idea of Almanac’s, probably from being sucked into Back to the Future as a kid!

image

So here is my go, a veritable buffet, corralling of some of the best bits of the year, mainly in your own words. There is so much good juice out there, for this Devo Avo to squeeze. I won’t focus on any of the big milestones centrally in the project, but rather your individual contributions and wins, you can go through our blogs bi-monthly updates, or check the GitHub repo’s themselves for an immutable source of truth. 🕵️

January​

Feb​

Mar​

  • Lewis Prescott, the Pactman himself, started his blog series and Podcast dedicated to our favourite topic with some of the players in the industry helping you calm the chaos.

Apr​

May​

  • Marie Drake again, delivering a contract testing 101 at her previous employer Zoopla where she evangelised Pact, she now works as a Developer Advocate as k6.io and is always putting out great content.
  • Tamerlan Gudabayev delivers a great post that helps what contract testing is, and where it fits in in your testing lifecycle.

June​

July​

  • Bas Dijkstra has been helping individuals, teams and organisations build quality systems for years with automation. This in-depth 6-parter are words from a sage.

Aug​

Whilst this feature in a Pact Broker, exists only in PactFlow (our commercial sponsor and guardian) the source code is open source and lives here for the underlying tool. If you want to help make improvements or use it to aid and augment your testing efforts with your OSS Broker, or if you use other mechanisms bar a broker to share pacts. If you do, we would love to what you are up to!

Sept​

Oct​

Nov​

Dec​

Pact Broker Graph

Pact saves the holidays, by ensuring those in charge of getting the turkeys to your table are deploying safely!

If you've done something great, and want to share it, get it listed - the site is open source and you can edit any page, we want to give you a platform to help amplify your voice!

Maybe there is time to get one last in before crimbo! No, only joking, that’s a wrap for this year's Pact Open Source Almanac, pop your feet up, enjoy your puds and hope to see your name in the book next year.

· 13 min read

Did you know, Pact is nearly 10 years old!

As the de-facto leader in contract-testing, the eco-system has grown to be vast, just take a look below

image

However today, I am going to take you on a little journey of how it came to be, and show you what is to come.

TL;DR​

A lot happens in 10 years. We’ve seen it all here at Pact, from the proliferation of micro services, to ever increasing protocols like Protobufs, GraphQL, transports such as gRPC, Websockets and MQTT, EventDrivenArchitectures and data pipelines or emerging standards such as OpenAPI, AsyncAPI and CloudEvents.

As we launch our Pact Plugin Framework bringing you new possibilities to the Pact eco-system, I’d like to invite you to try an interactive history lesson of Pact, from past, to present and beyond!

Pact and the Pact-Plugin Framework will unlock the possibility of testing multiple transport and content types. You will see Pact used for gRPC, Protobuf and CSV based messages. Hope it feeds your imagination of the possiblities, it certainly has for me!

image

If it piques your interest, you should sign up for our upcoming webinar to hear more about our exciting news and what it means for you and the software development community.

The birth of Pact Ruby​

Pact was originally written by a development team at realestate.com.au in 2013, born out of trying to solve the problem of how to do integration testing for their new Ruby microservices architecture. They threw together a codebase that was to become the first Pact implementation.

git add . && git commit -m 'Gem skeleton' && git push by James Fraser

Screenshot 2022-11-16 at 14 16 59

Ron Holshausen (at the time at DiUS, still one of the present day maintainers of Pact, and co-founder of PactFlow), first commit came shortly after.

Screenshot 2022-11-16 at 14 27 47

A few months later Beth Skurrie (then at DiUS, still one of the present day maintainers of Pact and co-founder of PactFlow ), joined one of the teams that was working with the Pact authors' team.

She had recently seen a talk by J.B.Rainsberger entitled "Integration tests are a scam", which promoted the concept of "collaboration" and "contract" tests, so she was immediately interested when she was introduced to Pact.

J. B. has since softed his message, as have we, I think we all mellow as we get older :)

Beth's first commit in Pact Ruby

Screenshot 2022-11-16 at 14 33 02

After trying (as most people do) to convince the authors that the provider should be the contract writer, she was soon convinced by Brent Snook, one of the original authors of Pact, of the value of consumer driven contracts. At this stage, she realised that what was missing in the current implementation was the ability to run the same request under different conditions, and "provider states" were born.

Viva la Pact Broker​

Screenshot 2022-11-16 at 14 28 48

What the heck is a Pact Broker anyway, Saf?​

The Pact Broker (as Pact was) being written to solve our own problem, which was trying to coordinate pact versions between projects.

It is an application that allows you to release customer value quickly and confidently by deploying your services independently and avoiding the bottleneck of integration tests, introducing a pact matrix.

It looks a little like this

image

By testing the Pact Matrix, you can be confident to deploy any service at any time, because your standalone CI tests have told you whether or not you are backwards compatible – no “certification environment” needed. And when there are multiple services in a context, this approach scales linearly, not exponentially like the certification environment approach.

Preaching the message​

Soon after, Beth decided that Pact idea was the best thing since sliced bread, and she hasn't stopped yacking on about it since. Hear Beth, Jon Eaves from REA and Evan Bottcher from ThoughtWorks speak at YOW!2014 in this YouTube video

Want a bit more of Beth? we told you she couldn't stop yakking

Ron began spreading the message, read a blog post from 2014 here

The birth of Pact JVM​

Pact spread around the codebases in the wider program of work at realestate.com.au, until it hit its first Java microservice. realestate.com.au had many JVM projects, so a group of DiUS consultants (including Ron Holshausen again) started the pact-jvm project on a hack day.

Screenshot 2022-11-16 at 14 37 32

Ron raised his first issue, https://github.com/pact-foundation/pact-jvm/issues/31, which led to his first PR

Screenshot 2022-11-16 at 14 43 27

You can watch a talk from Ron here talking about pact and Pact JVM

Like all grown up frameworks, processes are needed, and a Pact Specification was born.

Beth penned the first Pact test cases, which came to be Pact Specification v1.0.0

Screenshot 2022-11-16 at 14 45 42

It was at this stage that the authors realised that the Rubyisms in the format were going to have to be replaced by a non-language specific format, and the idea of the v2 pact-specification arose on Mar 27, 2014 though it would take a while (just over a year) before it became reality.

Screenshot 2022-11-16 at 14 53 18

Soon it became obvious that Javascript UIs would benefit greatly from using Pact with their backend APIs.

After tossing around the idea of implementing Pact yet again in another language, a decision was made to wrap the Ruby implementation (which was packaged as a standalone executable) to avoid the maintenance burden and potential of implementation mismatches. This became the pattern that was used for most of the following Pact implementations. Each language implemented a Pact DSL and mock service/verifier client, and called out to the Ruby mock service process/verifier in the background. The original Ruby JSON syntax was often used between the native clients and the mock service, as it was simpler to implement, however, the mock service took care of writing the actual pact in the v2 format.

The birth of Pact JS​

Three versions of Pact-JS have existed, Fuying created the first commit of DiUS/pact-consumer-js-dsl. A familiar face Beth pops along for her first commit.

A few days apart, DiUS/pactjs0 was created, the first commit by Jeff Cann. Ron dropped his first commit ultimately deprecating it a little while later.

Enter Matt Fellows, dropping his first commit. A man of many talents, Matt is still one of the present day maintainers of Pact, as well as co-founding PactFlow.

It's funny, JavaScript is akin to the bus service, you wait for ages and then three turn up at once 🤯.

Enter the still current Library, Pact-JS. It's first commit by Tarcio Saraiva.

A few months later, Pact-JS became the sole library going forward

This multi-language capability gave us the ability to start building cross-platform contract testing suites, as demonstrated below with JSON/HTTP interactions in laser focus

image

You can out HTTP based Pact in our interactive tutorial here, in either Java or JavaScript

Pact proliferates - Lead by example​

Since the implementation of the v2 format, newer features have been added, and the v3 and v4 formats add support for handing multiple provider states, messaging, and 'generators'.

One of the strengths of Pact is its specification, allowing anybody to create a new language binding in an interoperable way. Whilst this has been great at unifying compatibility, the sprawl of languages makes it hard to add significant new features/behaviour into the framework quickly (e.g. GraphQL or Protobuf support).

Wrapping the Ruby implementation allowed new languages to implement Pact quickly, however, it had its downsides. The standalone package worked by bundling the entire Ruby runtime with the codebase using Travelling Ruby, so it was large (~9MB). The native libraries also had to deal with the mock service process management, which could be fiddly on different platforms. It also made it difficult to run consumer tests in parallel, as each mock service process could only handle one thread at a time. The Ruby implementation was also lagging behind in feature development compared to the JVM, as Beth was spending more time on the Pact Broker.

To provide a single Pact implementation that could be used by all the required languages, the decision was made to create a reference implementation in Rust, that could be wrapped by each client language using FFI. The distributable package will be orders of magnitude smaller, and make it easier to run tests in parallel and avoid the process management issues, we have been slowly moving to our Rust core which solves many of the challenges that bundling Ruby presented.

It is worth noting that the "shared core" approach has largely been a successful exercise in this regard. There are many data points, but the implementation of WIP/Pending pacts was released (elapsed, not effort) in just a few weeks for the libraries that wrapped Ruby. In most cases, an update of the Ruby "binaries", mapping flags from the language specific API to dispatch to the underlying Ruby process, a README update and a release was all that was required. In many cases, new functionality is still published with an update to the Ruby binary, which has been automated through a script.

Beth often refers to the Ruby Goldberg machine, in a nod to Rube Goldberg.

image

We would love your engineering support in bringing efficiencies to our CI/CD processes used in our open source projects, or your artistic skills, if someone fancies drawing a Pact Rube Goldberg machine <3

Moving beyond HTTP​

But, the industry has continued to innovate since Pact was created in 2013, and RESTful microservices are only one of the key use cases these days - protocols such as Protobufs and Graphql, transports such as TCP, UDP and HTTP/2 and interaction modes (e.g. streaming or server initiated) are starting to become the norm. Standards such as AsyncAPI and CloudEvent are also starting to emerge.

image

For example, Pact has been a rather HTTP centric library, and the mixed success in retrofitting "message support" into all languages shows that extensions outside of this boundary aren't trivial, and in some respects are a second class citizen.

The reason is simple: HTTP doesn't change very often, so once a language has implemented a sensible DSL for it and integrated to the core, it's more a matter of fine tuning things. Adding message pact is a paradigm shift relative to HTTP, and requires a whole new developer experience of authoring tests, integrating to the core and so on, for the language author to consider.

You can read more about non-HTTP messaging with Pact 🔗 here

Please note this one is a pet-project work in progress but it does show off message testing in various pact languages (Java, JS, .NET, PHP, Python & Ruby)

image

Pact Plugin Philosophy​

Being able to mix and match protocol, transport and interaction mode would be helpful in expanding the use cases.

Further, being able to add custom contract testing behaviour for bespoke use cases would be helpful in situations where we can't justify the effort to build into the framework itself (custom protocols in banking such as AS2805 come to mind).

To give some sense of magnitude to the challenge, this table showed some of the Pact deficiencies across popular microservice deployments as of a couple of years ago

https://user-images.githubusercontent.com/53900/103729694-1e7e1400-5035-11eb-8d4e-641939791552.png

So the pact plug-in eco system was born, a way to allow new transport types, content matchers/generators and more to easily be added to the pact framework, without needing to wait for the core maintainers to roll it out. You can create your own, for public, private or commercial consumption!

image

Enough blurb, show me da code​

Whilst it may be quite technical for some, others will relish the possibilities this will unlock. If you want something or see a use case, but aren’t quite sure how to put it to reality, try out our demos and give us a shout via 🔗 canny, our feature request board, or 🔗 slack

To prove how easy it was, and as a nice little nod back to the Grandmother of Pact, Ruby. Your very own devo avo put his money where his mouth is and built his own.

Try out our pact plug-in framework here​

This will allow you to see Pact and the Pact-Plugin Framework to test multiple transport and content types. You will see Pact used for gRPC, Protobuf and CSV based messages. Hope it feeds your imagination of the possiblities, it certainly has for me!

And to anchor it back to a picture you probably know from our Pact docs, plugins just sit in the middle and help extend the capabalities

image

Choose Possibilities, Choose plugins, Choose Pact!

A thank you to those who got us here​

· 3 min read

Pact with more power – introducing the Pact Plugin Framework​

Today we share the news that your favourite contract testing framework comes Pact with more power! The new Pact Plugin Framework completes the missing piece to help development teams apply contract testing all their API technologies and use cases.

note

Replay the launch webinar to hear Matt and Yousaf explain the Pact Plugin Framework

Why we built the Pact Plugin Framework​

Loved by thousands of development teams globally, Pact was originally created to support the rise of RESTful microservices and has since expanded to support asynchronous messaging, becoming the defacto API contract testing solution.

As architectures have evolved, organisations find that the existing Pact contract testing framework may not support all of their use cases.

The industry has continued to innovate since Pact was created in 2013, and RESTful microservices are now only one of the key use cases today. According to SmartBear’s 2021 State of Quality report, we are seeing the growth of:

  • Protocols such as Protobufs and GraphQL (80% of organisations run multi-protocol and more than 60% of organisations manage three or more)
  • Transports such as gRPC, Websockets and MQTT
  • Newer interaction models such as streaming, async or server push
  • Event Driven Architectures and data pipelines
  • Emerging standards such as AsyncAPI and CloudEvent

Pact Plugin Framework now live​

The Pact maintainers have been acutely aware of the changing trends – we blogged about the idea for the Pact Plugin Framework in 2021 and have been actively chipping award at the roadmap item to enable developers everywhere to use contract testing where they previously couldn’t.

Hats off to Ronald Holshausen who undertook the mammoth task of standing up the Framework. With this, development teams can now harness the power of contract testing where they previously couldn’t, applying it to unique and emerging use cases and technologies - no matter the scale or the language, transport, protocol or content type.

How this new capability works​

Pact may have been applied to one team or application using RESTful microservices but another using GraphQL, have been unable to get the complete benefits of contract testing. The Plugin Framework is the answer – developers can build plugins for their custom needs, whether they open source the plugin or keep it closed source for in house only usage.

For those familiar with Pact, this is a substantial innovation. By having a single generic interface, the Plugin Framework side steps the problems of requiring the input of core maintainers to support a new feature and its constituent concepts that must be built into each client language.

Read the full use case for the Plugin Framework is explained in detail on the GitHub issue.

Getting started​

If you’re as excited by this new feature as we are, you can:

  1. Replay the launch webinar to hear Matt and Yousaf explain the Pact Plugin Framework
  2. Build your own plugin for any use case you and your team require – visit the guide to writing your own plugin
  3. Try out a pre-made plugin - visit the implementation guide for GPRC

· 6 min read

Welcome to the October Pact Open Source update! I’ve got some great things to share this month – new PRs, some awesome community members writing and talking about contract testing, plus a sneak peak of our upcoming Pact Plugin Framework launch! Let’s get into it.

Summary of the good stuff​

Merged PRs​

It's been a busy couple of months, and the PRs have been coming thick and fast. Here's a roundup of the top merged PRs.

PRs awaiting review​

You don't have to start writing code to get involved. There's always a raft of open pull requests eagerly awaiting review. You can check out the full list here, but I've pulled out some of the juiciest ones, which will make a big impact when they land. Any help on these would be greatly appreciated!

Updates to documentation and learning materials​

The following documentation is now live, or updated on the site:

  • Pact-Specification
    • All about the spec. Learn the history, philosophy, implementation support, migration notes, and more.
    • See it 👉 here
  • Pact-Plugins
    • The Pact plugins docs are now syncing from their readme, and displayed alongside our other Pact tooling.
    • Join us for the official launch next month
      • You can checkout the details and register 👉 here
  • Webhook template library
    • Updated to use the new contract requiring verification published event. We'd love your help to add new ones to the list!
    • See them 👉 here
  • Branch support in Client libraries
    • The list has been updated to show the latest state of play.
    • See it 👉 here
  • Community Repos
    • We've got a new showcase for Pact based repos in the wild. List yours here.
    • See them 👉 here
  • New articles
  • New workflow recommendations
    • A large scale migration of the docs, to use our new recommended configuration
    • See it in action in the updated CI/CD workshop 👉 here

Community corner - member shout outs​

Paulo Gonçalves​

We know it can be difficult to visualise the path to Pact Nirvana, the recommend CI/CD setup for your Pact integrations. Contributors have been adding their valuable experiences from lessons learnt in the field.

Paulo Gonçalves did just that in this repository. It exemplifies the best implementations of contract testing, reaching Pact Nirvana and having control via pipeline and pact-broker in a completely reliable way. This provides security to deploy quickly, safely, and more frequently.

Please give the repository a star ⭐ as this is a great motivator for Paulo to continue to create quality software content, which is 100% free to use!

PLUS extra kudos to Paulo, who delivered a contract testing workshop entirely in Portuguese for our Portuguese-speaking friends!

Eric Deandrea and Holly Cummins​

Many thanks to Eric Deandrea and Holly Cummins, who co-delivered a fantastic, funny talk at Devoxx Belgium on "How to avoid common pitfalls with modern microservices testing". I enjoyed watching this, and think challenging mental models is a wonderful way to break down an often complex and misunderstood subject

Holly has been particularly active whilst she worked in the IBM Garage, so it's wonderful to see her delivering fantastic talks.

Liran Tal​

A talented Developer Advocate, Liran Tal at Snyk is a long-time friend of the Pact Open Source Foundation. He often tours the conference circuit in his easily recognizable green hat.

Liran created the incredible Comprehensive Guide to Contract Testing APIs in a Service Oriented Architecture". He's also the author of awesome-contract-testing because, as you already know, contract testing is AWESOME! 👌 And because we love videos, I recommend his talk Consumer-Driven Contract: A better approach for API Testing from APIdays Barcelona.

Thank you to all our community members. The effort you put into our community is appreciated!

Become a contributor​

As the Pact Community Shepherd, I'm dedicated to making it as easy as possible to get involved in the Pact Open Source Project.

There's no minimum time commitment, but we highly value regular, committed contributions, as these make the Pact OSS vibrant and healthy.

Not sure where to start?

With the impending official launch of the Pact Plugins Framework, we're on the lookout for enthusiasts who want to build their own profile and be a part of the future of Pact. We're looking for individual people or teams interested in extending Pact by creating a plugin

  • such as Avro or GraphQL content type or a Websockets transport.

If this sounds like something you'd like to know more about, join us next month at our launch event to learn about the Plugin Framework and how you can get involved. You can checkout the details and register 👉 here

Whether you've participated before or are ready to take the first plunge, the team and I are here to support you! Need extra convincing? I wrote about why participating in OSS projects is awesome, for DevPro Journal!

You can also read our Pact Open contributing page to learn about the different ways to get involved in Open Source, no matter what role or skillset you hold.

That's all for now. Catch you on Slack!

  • Yousaf Nabi -- Developer Advocate at PactFlow and Community Shepherd at Pact.

· 5 min read

Welcome to the Pact Open Source August 2022 update!

I have some awesome updates for you this month!

‌As always, thanks to all of the contributors who have made this happen, if you haven’t been mentioned here but wish to appear in a later update, feel free to reach out to me on Slack.

Pact JS​

Pact JS 10.x.x is now live

Get it here 👉: https://github.com/pact-foundation/pact-js

Summary of the good stuff​

  • Speed! - It’s quick, blisteringly quick. You’ve probably heard people talk about just how good Rust is, they weren’t wrong.
  • Full support for binary payloads (both HTTP and Async) and multi-part uploads
  • For Async, the ability to specify and verify message metadata
  • XML support
  • Ability to create and verify both v2 and v3 specification pacts
  • Support for all v3 matchers and generators, and other v3 items (such as multiple provider states with parameters)
  • Improved support for Hypermedia APIs such as HAL and Siren through url and arrayContaining
  • Support for dynamic IDs in requests via provider state injected values (fromProviderState matcher)
  • arrayContaining and eachKeyLike matchers for improved array matching
  • Ability to modify request bodies and headers during verification (via requestFilter on the provider)

Docs​

Community corner – member shout outs​

Big props to the many who have helped make Pact-JS such a success, but we wanted to take a moment to give a shout out for a few whose contributions have really propelled adoption and the beta, into GA. We of course, can't forget Matt Fellows who is a machine that never sleeps, each contribution, helps Matt get 5 more minutes with the kids. Save a Matt, make a contribution.

Ron Holshausen​

Ron has been diligently plugging away at the Rust core, a Pact implementation written in Rust. It supports the V3 Pact specification and V4 Pact specification and provides shared libraries that can be used in other languages via foreign function interfaces (FFI).

It has now been adopted in Pact-JVM, Pact.Net, Pact-JS and Pact-Go, and although we are still ironing out issues, we are so grateful for the time Ron spends in trying to improve the landscape. I’ll let Ron explain some of the journey

One of the strengths of Pact is its specification, allowing anybody to create a new language binding in an interoperable way. Whilst this has been great at unifying compatibility, the sprawl of languages makes it hard to add significant new features/behaviour into the framework quickly (e.g. GraphQL or Protobuf support).

We have attempted to combat this time-to-market problem, by focussing on a shared implementation (the "shared core") in many of the languages. We initially bundled Ruby, because it was convenient, but have been slowly moving to our Rust core which solves many of the challenges that bundling Ruby presented.

The "shared core" approach can only take us so far, and we need another mechanism for extending behaviour outside of the responsibilities of this core. This is where I see a plugin approach working with our "shared core" model.

Tim Jones​

Pact-JS wouldn’t be half of what it is today, without Tim Jones. Outside of the PactFlow co-founders and myself, Tim has the most GitHub and Slack contributions of anyone in the Pact community, it really is staggering. He always delivers gems of well thought advice with a smile, and is an absolute delight to work with. He took a well earned break from being a full-time Pact maintainer earlier this year, but if you’ve had the time to visit the Pact Slack group, you’ve probably seen him armed with Tim’s Tech Tidbits, which we all need to encourage him to make into a YouTube series.

Aligntech​

What has the team at Aligntech been up to? Sponsoring some of the initial implementation and XML!

Much respect to Aligntech for sponsoring the initial implementation of Pact JS v3 and XML support, we are proud to show them on our website, along with other great companies and contributors who have helped Pact become as widely adopted as it is today.

Check out Aligntech and the great work they do.

Artur Neumann​

Thanks to Artur Neumann for driving beta adoption and usage (via owncloud) and providing an incredible amount of feedback on the Pact V3 release. One look at the pact-js issues and PR list shows Artur's energy in raising issues in the V3 beta, or dropping in helping contributions to the codebase.

This feedback is critical in helping us improve the tooling for all of our users, and is also highly rewarding, seeing something you’ve created or had a hand in, helping others, even if it's not quite right.

Become a contributor​

If you’re passionate about Open Source, Pact or a specific language, get involved as a maintainer. There’s no minimum time commitment and you can get involved on your own terms. One thing that does make the Pact OSS so great is regular, committer contributions.

Read our Contributing page to find out many of the different ways you can get involved in Open Source, no matter what role, or skillset you hold.

That's all for now, catch you next month!

  • Yousaf Nabi — Developer Advocate at PactFlow and Community Shepherd at Pact.

· 5 min read

Welcome to the Pact Open Source July 2022 update!

Hope you have all been enjoying the sun whenever you are in the world, unless like our Pact core team, you live in Australia. Sweaters at the ready.

This month has seen a flurry of activity across the open source space, with many new contributors helping in a multitude of ways, so we will call out some notable mentions.

‌Thanks to all of the contributors who have made this happen, if you haven’t been mentioned here but wish to appear in a later update, feel free to reach out to me on Slack.

Specific language updates​

Golang​

Attention Golang users - the latest 2.x.x is out (2.0.0-beta.13)! 🚀This is quite a big change from the past release, namely we’ve been thinking about the API design with the introduction of V4 and plugins.

Summary:

A word from our PactFlow co-founder & pact-go maintainer Matt Fellows

Because the API is more complex, we’ve used a type state builder pattern to force which options can be used at any point in time, and ensure that pre-requisite methods are called in sequence. We are still not 100% happy with the HTTP package layout (and requiring V2/V3/V4 prefixes on a number of types), so there might be another refactor in that space, but mainly we think it would just be the names of types and packages that could change. We will tidy up the documentation over the next few days, but look to the examples folder in the short term if you’re wondering what’s changed. Our core maintainer found refactoring the existing examples fairly straightforward, so we hope you do too.

Chat with us in: #pact-go

Node JS​

Pact-JS - Pact specification V3 beta now supports modifying the request body in the verifier which has been a long standing issue and more work is progressing on stabilizing for General release: https://github.com/pact-foundation/pact-js/tree/feat/v3.0.0/ (v10.0.0-beta.60). Follow the roadmap progress.

Chat with us in: #pact-js

Rust​

Pact FFI 0.3.3 was released https://github.com/pact-foundation/pact-reference/releases/tag/libpact_ffi-v0.3.3 which brought in add retries to the provider state change calls along with some bug fixes

Chat with us in: #pact-rust

.Net​

PactNet 4.1.0 is now released and pushed which allows publishing verification results for URI sources

See the upgrade guide for details of the rewrite and how to upgrade from 3.x to 4.x

Chat with us in: #pact-net

Community Corner​

You lot were busy this month, despite the sunny climes, don’t forget to nip outdoors!

Just look at all the merged Pull Requests that have come in from the community.

You are all awesome

Pull Requests – Features/Fixes​

Big call out to Dave Clissold who performed the first two PR’s in this list, which resolved one of the most active outstanding issues in Pact-JS and indeed across the pact-foundation. It was 3 years old, and shows how difficult it can be to get changes in, with ever-changing demands, but you can get involved, and help deliver the features you want now, and we can help guide you along

Pull Requests – Docs​

Much respect to Eduardo Lopez for adding illustrations to our docs, to help guide people around the OSS Broker UI, it’s not all about the code, and there is always a need to keep our documentation up to date and consistent. Found a snag, patch it up with a new PR and get some committer kudos. It can be as easy as adding screenshots, and it will make a massive difference

Pull Requests – Maintenance Stuff​

Shout out to Artur Neumann, for being a pivotal member in supporting the pact-js beta rollout and helping make Matt’s life a little easier.

Community Spotlight – Mike Geeves​

We haven’t spoken enough about Mike Geeves from Bearly Compiling :chef kiss: - He has been working on Pact on and off, over the last couple of years, and has been thoroughly confused enough by our examples at times, to want to do something about it!! Mike has helped me during my time joining the PactFlow team and has been great for the occasional rant, and productive conversations that always end up in more work. I don’t think we’ve quite cracked pomodoro.

So why did Mike start tickling Pact?

I tend to try and come up with ideas, which I can at least PoC enough to demonstrate what I mean, and then see if there's any uptake of the idea to progress, if not bin it, which has led to the slightly bizarre situation where my first ever open source contribution was in Rust for pact-rust, and I cannot code in Rust 😂

So what are Mike and I up to now? We are looking at our examples with a particular focus on our support for Message Pacts across the different libraries and building up a compatibility matrix with documentation driven from examples. Want to join us on the adventure? Get involved in #documentation over at slack.pact.io

That's all for now, catch you next month!

  • Yousaf Nabi — Developer Advocate at PactFlow and Community Shepherd at Pact.

· 8 min read

Welcome to the Pact Open Source June 2022 update!

This month has seen a flurry of activity across the open source space, with many new contributors helping in a multitude of ways, so we will call out some notable mentions.

‌Thanks to all of the contributors who have made this happen, if you haven’t been mentioned here but wish to appear in a later update, feel free to reach out to me on Slack.

Specific language updates​

.Net​

PactNet 4.0.0 is now released and pushed, have a look.

See the upgrade guide for details of the rewrite and how to upgrade from 3.x to 4.x

Some words from our amazing maintainer Adam Rodger:

Release Announcement Now that we've been in beta for a good while I think we're ready for a proper release of PactNet 4.0.0. I think we've ironed out any teething issues now, so thank you to all those that have participated in the beta and raised issues for me to fix. I've got the current latest beta running in production at my employer and everything appears to be working OK. Of course there will be more features and things to add in the future, but I think the core functionality is all there and the API can be considered stable. Adam released PactNet 4.0.0 on 6 June and is now enjoying a well-deserved holiday. Thank you, Adam.

Chat with us in: #pact-net

NestJS + Pact = <3​

Omer Morad, our friend in, Tel Aviv, Israel, is a backend-oriented developer, OOP flavored, in a distributed systems world and also a Web artisan, TypeScripter, open-source enthusiast, and guitar player.

He recently brought in https://github.com/pact-foundation/nestjs-pact to the pact-foundation and we would love to get it featured on the awesome-nestjs repo.

Are you using NestJS + Pact? Want to help build out an example? Chat with us in: #pact-nestjs

Pull Requests​

  1. Pact-Reference - Allow BrokerWithDynamicConfiguration to publish results by Kageru

  2. Pact-JVM – Support for providerVersionBranch option to replace providerVersionTag with thanks to Ben Pilgrim & Praveen Erode Mohanasundaram

  3. Pact-JVM – Rejeeshg for updating builds to resolve vulnerabilities. Dependabot or similar would be great here to save the manual effort! PR’s welcome :)

  4. Pact-PHP / Pact-Ruby / All the things – Shout out to Lewis Cowles and Jonathon Padfield.

Lewis has been working hard on improving alpine support, fixing the pact-php build after a URL change and created a number of issues against the pact-php repo to help the maintainer. Lewis said:

This one introduces scheduled builds so that if a maintainer gets "life happen" then you can still as an org know if that package is failing, and get visibility before a customer comes to you. It's a thing I use if I want to show something so that I know it should always be build-able.

And thanks Jonathon for updating pact-ruby-standalone to use travelling ruby 2.4, we are testing this out now and hope to roll this out across all the libraries soon.

Bi-Directional Adapters​

WireMock & .Net​

Using WireMock & .Net and want to benefit from Bi-Directional Contract Testing?

🔥 Now you can generate Pact 🔗 contracts from your WireMock Server, check it out here.

Thanks Stef Heyenrath 😍 for the his work in the community!

Pact-MSW Adapter​

Pact-MSW-Adapter now has new features and a quick start guide, an international effort with contributors from the UK, Argentina, Spain and Canada. Shouts go out to:

  1. Kiko Ruiz Llorret for request query support
  2. Nicholas Simons for post request support
  3. And we cannot forget Juan Cruz for being an early trailblazer and improving the developer experience vastly

Create your own adapters to use in Bi-Directional Contract Testing​

Inspired by our list of tools, but don’t see your favourite? Create your own! Here's how:

  1. Convert your mock format to a supported Pact specification format - we recommend v2 at the moment - see a jsonschema to test against
  2. Create an example - see our existing supported tools and demos
  3. Submit a PR to to get listed

Our awesome community​

Developer Relations at Pact-Foundation now has a new home @ https://github.com/pact-foundation/devrel

We recently hooked up Orbit.love, to give us a bit of a glance across our open source estate, and we were able to pull out well over 2k different contributions from just the top 15 in the leaderboard excluding PactFlow’s co-founders!

Particular shout-out to Timothy Jones, who has been on an epic crusade to empower those around him with words of contract testing wisdom and delightful development life-hacks. The Pact world wouldn’t be the same without you all, and we appreciate every contribution big or small.

Pact contributors

Pact contributors

Community is everything for us. And that’s why we have big plans to dive into the various initiatives and determine how we can acknowledge and support members and the community as a whole for their time and dedication. Without each of you ❤️ Pact would not be the leading open source cross-language distributed contract testing framework! Like us, you should be so proud that you’re helping free the world from the burden of microservice spawl and deployment headaches.

Other ways to get involved with Pact​

The Pact ecosystem is vast, I will be sharing some posts over the upcoming months, showing the size of the estate, and looking to gain insight from you, the community, as to how we can reduce the signal-to-noise and help reduce the cognitive load required to navigate the path the Pact Nirvana in your own organisation.

There are a multitude of ways, and you don't need to be a code wizard to start:

  • 📙 Docs - Our documentation is the primary way to communicate to our users, you can help out with small changes like a typo, help rewrite larger pieces, or add new content. Think of it as a open source contract testing wiki, and you are all the curators.
  • 🚀 Code - We have implementations across multiple languages, and not all of them are at feature parity. Sometimes you might need that feature, or you've found a bug. Every pact-foundation repository is open-source, and contains a contributing guide to help you get started. Maybe you are building your own Pact tooling, let us know, we would love to shout about it.
  • Roadmap / Feature Requests - The Pact roadmap is available on Canny, where you can see some of the teams current and upcoming priorities in the OSS space. You can request new features, or browse the list and vote/comment on ones you would love to see. See one that particularly resonates? You could help work on it, reach out via Slack and we can help guide you through your contribution.
  • Recipes - The community use our tools in a variety of different ways, and solve various challenges that others could benefit. Got something to share? Why not add a new recipe to the site?
  • Workshops - We created a number of workshops, across several languages. Is there a language implementation not covered in the workshop? Maybe you've created or seen some amazing workshops out there in the wild? Add it to the list, or if you are the author, you can discuss bringing your workshop under the Pact-foundation, if you feel all Pact users could benefit
  • Blogs, Videos & Articles - Articles about contract testing are appearing left, right and centre, I can't keep up. Make sure our reading list doesn't get dry, by adding your favourite content to the list
  • Events - Meetups, in person, it feels like a distant memory, but as the doors start opening again, and dinner is provided, people are beginning to flock outdoors. Have you got a meetup or event planned? Already had one and recorded it? You can add them to the list, and let us and the community know about it on Slack.
  • Helping those in the community - We know many of you in the community love sharing your contract testing knowledge with others, you can see the various places our users land for help, sometimes in GitHub issues, Stack overflow, or Slack. You are welcome to help them out whether you are new to Pact, or a seasoned pro, all questions, opinions and thoughts are welcome.
  • Pact champions - Are you like our co-founder Beth Skurrie, who decided that Pact idea was the best thing since sliced bread, and she hasn't stopped yacking on about it since. Want to share your knowledge, and build your social profile in the world of tech with a global platform? Please get in touch with me on Slack, we want to support the amazing work you do! If you love Pact, and want to help the world worry less about micro-service deployment, why not join us on our journey. Who knows where it might lead.

That's all for now, catch you next month!

  • Yousaf Nabi — Developer Advocate at PactFlow and Community Shepherd at Pact.

· 6 min read

Welcome to the inaugural Pact Open Source update!

This month PactFlow officially joins the SmartBear family, and with this, the Pact OSS community will be supported by SmartBear. We're excited to join SmartBear and together, expand contract testing to more developers and testers. Read more about what this means for you.

The contributor community has been hard at work uplifting key languages to integrate our Rust shared core, enabling support for the latest features in the specification, plugins and more.‌ ‌‌ ‌Thanks to all of the contributors who have made this happen.‌

Specific language updates​

.NET​

Pact-net: Next major release is not far away, with the Pact specification v3 beta stabilising: https://github.com/pact-foundation/pact-net/ (v4.0.0-beta.3).

Chat with us in: #pact-net

Golang​

Pact-go: Next major release is not far away, with the Pact specification v3 beta stabilising: https://github.com/pact-foundation/pact-go/tree/2.x.x (v2.0.0-beta.10).

Chat with us in: #pact-go

Node JS​

Pact-JS: Pact specification V3 beta now available: https://github.com/pact-foundation/pact-js/tree/feat/v3.0.0/ (v10.0.0-beta.59). Follow the roadmap progress.

Chat with us in: #pact-js

Swift​

Pact-Swift: Pact specification V3 support and provider side verification in Swift: https://github.com/surpher/PactSwift.

Chat with us in: #pact-swift

Scala​

Scala-Pact: 🚧 ITV Pact is moving to maintenance mode and will only support up to Pact specification V2.

pact4s: The future is pact4s, which is a Scala wrapper of Pact JVM and currently supports up to Pact specification V3.

Chat with us in: #pact4s

Python​

Pact-Python: Message support was added in 2021 to enable testing of asynchronous integrations such as RabbitMQ or Kafka (https://github.com/pact-foundation/pact-python/pull/194, https://github.com/pact-foundation/pact-python/pull/251).

Chat to us in: #pact-python

V4 Pact Specification​

Pact specification V4 is here! We worked hard on listening to the community, after the release of v3, 5 years ago. We consolidation many of the requests people made about things that haven't worked quite properly. One of the biggest changes is consolidation the file format to allow for HTTP and message interactions with a single file.

Plugins, Protobufs and gRPC (oh my!)​

Back in September 2021 Matt introduced us to The case for contract testing Protobufs, gRPC and Avro.

We are pleased to announced initial support for testing gRPC interactions via plugins has been added to Pact-JVM (for Junit5) and Pact-Rust including the shared core, enabling distribution to other client libraries.

We have released an official PactFlow Protobuf / gRPC plugin for Pact.

Join the Developer Preview Program for updates, or chat to us in #protobufs.

Pactman​

Hungry for docs, but don't want to move from your terminal? Type npx pactman for a treat 😲

🔍 pactman - search the pact docs from your terminal 👩‍💻

Pactman

Get involved​

The Pact ecosystem is vast, I will be sharing some posts over the upcoming months, showing the size of the estate, and looking to gain insight from you, the community, as to how we can reduce the signal-to-noise and help reduce the cognitive load required to navigate the path the Pact Nirvana in your own organisation.

There are a multitude of ways, and you don't need to be a code wizard to start:

  • 📙 Docs - Our documentation is the primary way to communicate to our users, you can help out with small changes like a typo, help rewrite larger pieces, or add new content. Think of it as a open source contract testing wiki, and you are all the curators.
  • 🚀 Code - We have implementations across multiple languages, and not all of them are at feature parity. Sometimes you might need that feature, or you've found a bug. Every pact-foundation repository is open-source, and contains a contributing guide to help you get started. Maybe you are building your own Pact tooling, let us know, we would love to shout about it.
  • Roadmap / Feature Requests - The Pact roadmap is available on Canny, where you can see some of the teams current and upcoming priorities in the OSS space. You can request new features, or browse the list and vote/comment on ones you would love to see. See one that particularly resonates? You could help work on it, reach out via Slack and we can help guide you through your contribution.
  • Recipes - The community use our tools in a variety of different ways, and solve various challenges that others could benefit. Got something to share? Why not add a new recipe to the site?
  • Workshops - We created a number of workshops, across several languages. Is there a language implementation not covered in the workshop? Maybe you've created or seen some amazing workshops out there in the wild? Add it to the list, or if you are the author, you can discuss bringing your workshop under the Pact-foundation, if you feel all Pact users could benefit
  • Blogs, Videos & Articles - Articles about contract testing are appearing left, right and centre, I can't keep up. Make sure our reading list doesn't get dry, by adding your favourite content to the list
  • Events - Meetups, in person, it feels like a distant memory, but as the doors start opening again, and dinner is provided, people are beginning to flock outdoors. Have you got a meetup or event planned? Already had one and recorded it? You can add them to the list, and let us and the community know about it on Slack.
  • Helping those in the community - We know many of you in the community love sharing your contract testing knowledge with others, you can see the various places our users land for help, sometimes in GitHub issues, Stack overflow, or Slack. You are welcome to help them out whether you are new to Pact, or a seasoned pro, all questions, opinions and thoughts are welcome.
  • Pact champions - Are you like our co-founder Beth Skurrie, who decided that Pact idea was the best thing since sliced bread, and she hasn't stopped yacking on about it since. Want to share your knowledge, and build your social profile in the world of tech with a global platform? Please get in touch with me on Slack, we want to support the amazing work you do! If you love Pact, and want to help the world worry less about micro-service deployment, why not join us on our journey. Who knows where it might lead.

That's all for now, catch you next month!

  • Yousaf Nabi — Developer Advocate at PactFlow and Community Shepherd at Pact.

· One min read

When a Pact Broker instance has accumulated large amounts of data, its performance can start to degrade. A new feature has been released in the Pact Foundation's Pact Broker Docker image to allow old, unused data to be removed automatically from the Pact Broker at a configured schedule. The clean up can either run on a cron schedule from the Pact Broker application container, or it can be executed from an external location, independent of the running instance. Read more about the clean feature in the Maintenance section of our Pact Broker docs.

· 6 min read

tl;dr​

Changes to the contract made by the consumer teams can no longer break the provider builds. Hooray!

Read on for the longer version...

The problem

Pact is a consumer driven contract testing tool that allows you to test your integration points without dependencies. The consumer is tested with a mock provider, and a contract ("pact") is generated from the tests. The contract is taken over to the provider and then "verified" to make sure that the real provider and the mock provider behave the same way.

During the verification step, each request from the contract is replayed against a running test instance of the provider, and the responses are compared to the expected responses. If they match, the verification is successful. If they do not match, the verification has failed, and the provider build fails.

In the context of an existing contract, there are two reasons that the pact verification step can fail when it was previously passing.

  1. The provider has changed.
  2. The contract (consumer expectations) has changed.

In scenario 1, we actually want the provider build to fail, as this is the purpose of contract testing - it prevents breaking changes being made by the provider for existing consumers.

In scenario 2 however, when the contract has changed, the failure of the provider build is an undesirable consequence of the workflow. The contract may have changed due to the teams following the "consumer driven" nature of the process whereby the expectations come before the implementation (TDD for services); there may be an issue with the provider state data; or there may just be incorrect expectations about existing behaviour.

The fact that the provider build can be broken by new or incorrect expectations in the contract (which is effectively written by the consumer team) is one of the biggest problems people have with Pact. It leads to contention between teams, and in some cases, stops teams using Pact at all.

One solution could be to run all pact verification builds in such a way as to ignore any failures that might occur, but then we'd miss being alerted to potentially breaking changes by the provider, which defeats the purpose of using contracts in the first place.

What we want is a way to get feedback on changed contracts without breaking the provider build, but for the build to correctly identify and fail when a provider is making a breaking change.

The solution

The Pact team is extremely happy to introduce the new "pending pacts" feature.

Those familiar with automated testing frameworks have probably come across the term "pending" tests. These are tests that have a particular flag on them that causes them (depending on the framework) to either be skipped, or if executed, to not fail the build. In the case of Pact, we want the feedback we get from execution, so rather than a "pending pact" being one which will be skipped, it is one which can be verified without its failure causing the overall verification task to fail.

So how does the Pact verification tool know if a pact is in "pending" state or not? This is where the Pact Broker comes in. The Pact Broker is a service that sits between the consumer and provider builds, and allows the contracts and verification results to be exchanged between the consumer and provider teams. The Pact Broker can identify when a contract with new content has been published, and when it is retrieved for verification by the provider's Pact library, it flags it as "pending". The Pact library executes the verification, ensuring that the status of the overall task is not affected by any failures. At the end of the verification process, the outcome of the verification is published back to the Pact Broker. Once the pact has been successfully verified it ceases to be "pending". This means that any subsequent verification failures for a pact with identical content will cause the provider build to fail, as the failure can now only be due to a change in the provider code.

How do I start using pending pacts?

Head to https://docs.pact.io/pending for information on how to setup your Pact Broker to enable this feature (it is enabled by default on https://pactflow.io).

To start getting the benefit of this new and improved workflow, you will need to upgrade to the latest version of the Pact Broker and your Pact testing libraries. Consult the documentation for your language to find out how to enable the pending feature.

If you're on a consumer team, and have, until now, relied on the provider team to alert you to verification failures, you'll want to make sure that you're getting this information via another channel now. We recommend that you use can-i-deploy to make sure that you aren't deploying with a broken contract, and that you set up webhooks to ensure you're made aware of the verification outcomes of your contracts as soon as possible (eg. posting to a team's Slack channel, or updating a Github commit status.)

A note for advanced Pact Broker users​

If you're not using tags in the Pact Broker you can skip this section! But take the time you've saved reading the next paragraph, and spend it reading up on tags because if you're not using them, you're probably not getting the full benefit out of your Pact Broker.

Tag users - the "pending" status is calculated using the provider version tag(s) that will be published with your verification results. The provider tags are sent to the Pact Broker when retriving the list of pacts to verify, and are used to determine the pending status for each pact returned. For example, once you have successfully verified a pact with a version of the provider tagged as feat-x, then pacts with the same content will be non-pending for any subsequent verifications by a feat-x version. However, the same pact could still be in "pending" state for the master.

Why is this important? It means that if you're using a feature branch tagged feat-x on your provider to implement a new interaction, the pact will remain pending on your master branch even after it passes verification on the feat-x branch. It will only become non-pending on master once the feature branch has been merged in, and the pact has passed verification on the merged code.

Conclusion

We're pretty excited about this new workflow, and we hope it will help make your experience testing with Pact a smoother and happier one. Let us know how you find it on the Pact Foundation Slack (join here).