While REST continues to dominate, 23% of respondents claim to actively use GraphQL. This follows the multi-protocol trend we’ve observed for years now. There’s no doubt in our minds that adoption for GraphQL will continue to grow YoY because of its many benefits.

If you’re new to the contract testing game, GraphQL or just need a refresher, follow along as we dive deeper into contract testing for GraphQL.

What is GraphQL?

GraphQL is a query language for APIs, enabling declarative data fetching from a variety of sources such as a database or another API. Unlike REST APIs, which requires users to stitch multiple resources together, GraphQL retrieves all required data in one request, using types and fields instead of individual endpoints with very specific data models.

GraphQL services can be implemented in any programming language, while the GraphQL schema language ensures consistency in a language-agnostic manner. Schemas define object types, each representing a fetchable object with associated fields. This offers a familiar structure for developers.

For example, the following GraphQL Schema shows how you might query to get a specific Product:

type Product { 

    id: ID! 

    name: String! 

    type: String! 

    price: Int! 

} 

  

type Query { 

    product(id: ID!): Product 

}

Each field on a type is backed by a resolver function, provided by the GraphQL server developer. When a field is executed, the corresponding resolver generates the next value. This approach streamlines back-end development by eliminating the need for writing specific responses or versioning APIs. Front-end teams benefit from requesting only the required data, enhancing both back-end and front-end performance.

What are the benefits of using GraphQL?

GraphQL offers several key benefits for developers and applications. One of the primary advantages is its flexibility, allowing clients to request precisely the data they need, with less over-fetching and under-fetching of information. This results in more efficient and faster data retrieval, improving the performance of applications.

Additionally, GraphQL promotes a strong type system, offering auto-generated documentation, making it easier to understand the available data and operations. Overall, GraphQL enhances the developer experience, optimizes data transfer, and enables a more streamlined and responsive approach to building modern, data-driven applications.

The case for contract testing GraphQL

Contract testing is a software testing approach that focuses on the interactions between different software components to ensure they can communicate effectively. It does so by capturing a contract, which records the specific details of their interactions – such as HTTP requests and responses – and the scenarios in which they are valid.

You may then ask what is the value of contract testing GraphQL, which itself has a form of contract already – the GraphQL Schema?

Whilst this is a good point, there are several reasons to consider contract testing for GraphQL to prevent production issues:

• It doesn’t prevent breaking changes– the GraphQL schema can change on the server side and any clients expecting the previous behaviour will be broken.

• Schemas are abstract and insufficient to describe API semantics– which can lead to incorrect assumptions about how the API is supposed to work.

• GraphQL’s deprecation feature is at runtime – too late to notify any users of the API!

Contract testing with Pact resolves this, as each scenario is made explicit via the “specification by example” approach.

Here are some of the benefits of using contract testing for GraphQL APIs:

• Gain visibility into consumers: knowing who your consumers are and what they need gives you greater freedom to evolve your API

• Increased confidence: prevent releasing breaking changes to users, before you commit

• Improved communication: by making scenarios explicit, you can improve communication between developers who are working on different GraphQL APIs (This is because contract tests provide a common reference point for understanding the expected behavior of the APIs)

• GraphQL often relies on HTTP services downstream, so adding contract tests in these layers will improve confidence all of the way down the stack

How to test your GraphQL using PactFlow

It turns out contract testing GraphQL is not a lot different than testing other HTTP services, as GraphQL is just an abstraction over HTTP.

1. Install Pact client language SDK

Pact supports over 10 languages., iIn this example, we will use Java. See https://github.com/pact-foundation/pact-jvm for installation instructions.

2. Write consumer test

The consumer and provider can be implemented in any programming language. The consumer will need to be able to send GraphQL queries and mutations, and the provider will need to be able to respond to GraphQL queries and mutations.

@ExtendWith(PactConsumerTestExt.class) 

@PactTestFor(providerName = "graphql-api") 

public class ProductsPactTest { 

  @Pact(consumer="graphql-consumer") 

  public RequestResponsePact getProduct(PactDslWithProvider builder) { 

    // Arrange: establish the mock and test conditions 

    PactDslJsonBody body = new PactDslJsonBody(); 

    body 

      .object("data") 

        .object("product") 

          .stringType("id", "10") 

          .stringType("name", "product name") 

          .stringType("type", "product series") 

        .closeObject() 

      .closeObject(); 

    final String query = """ 

      { 

      "query": "{ 

        product(id: 10) { 

          id 

          name 

          type 

        }} 

      "} 

      """; 

    return builder 

      .given("a product with ID 10 exists") 

      .uponReceiving("a request to get a product via GraphQL") 

        .path("/graphql") 

        .headers(Map.of("content-type", "application/json")) 

        .method("POST") 

        .body(query) 

      .willRespondWith() 

        .headers(Map.of("content-type", "application/json")) 

        .status(200) 

        .body(body) 

      .toPact(); 

  } 

  @PactTestFor(pactMethod = "getProduct") 

  @Test 

  public void testGetProduct(MockServer mockServer) throws IOException, URISyntaxException { 

    // Act: call the API client we are testing 

    Product product = new ProductClient().setUrl(mockServer.getUrl()).getProduct("10"); 

  

    // Assert: perform any other relevant unit testing checks, such as the product unmarshaling correctly 

    assertThat(product.getId(), is("10")); 

  } 

}

3. Verify the GraphQL API (Provider)

Now that we have our contract file (locally), let’s validate it. To do this, we simply need to start our GraphQL API on our machine, and tell Pact:

1. Where the API is running (here, on port 8080)
2. Where to find the pact file to validate (a local directory)

@ExtendWith(SpringExtension.class) 

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT) 

@PactFolder("path/to/pact/directory/from/step/1") 

class ProductsPactTest { 

  @Autowired 

  ProductRepository repository; 

  @BeforeEach 

  public void setupTestTarget(PactVerificationContext context) { 

    context.setTarget(new HttpTestTarget("localhost", 8080)); 

  } 

  @TestTemplate 

  @ExtendWith(PactVerificationInvocationContextProvider.class) 

  public void pactVerificationTestTemplate(PactVerificationContext context) { 

    context.verifyInteraction(); 

  } 

  @State("a product with ID 10 exists") 

  public void setupProductX010000021() throws IOException { 

    System.out.println("a product with ID 10 exists"); 

    repository.save(new Product(10L, "test", "product description", "1.0.0")); 

  } 

} 

That’s it – we have now performed a basic GraphQL contract testing. To do it properly, you should integrate this with PactFlow and into your CI/CD pipeline.

To learn more, try out our GraphQL example or check out our documentation.

Avoid FOMO, try it out now

GraphQL is a powerful and flexible API query language that offers a number of benefits for both developers and users. It is a good choice for building a wide variety of applications, from simple websites to complex enterprise systems. As microservices architecture continues to increase in demand, so will GraphQL’s popularity.

Ready to start contract testing your GraphQL? Try PactFlow for free now.

In SmartBear's  State of Software Quality API (2023) report, 9% of respondents reported using gRPC in their organisations, with 7% also reporting the use of Protobuf. This follows a trend we've seen over multiple editions now, where a majority of organisations operate within a multi-protocol environment (81%), and 57% have to manage 3 or more protocols.

In this article, we look into gRPC and Protobuf, and discuss their benefits, the types of breaking changes they are susceptible to, and finally and how Pact and PactFlow can be used to support gRPC contract testing to improve safety and reliability.

What is gRPC?

From https://grpc.io/:

gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.

In our experience, gRPC is often used as a replacement for internal service communications over the popular JSON/HTTP – or REST paradigm – where domain concepts (resources) are represented and transferred over HTTP, and HTTP verbs used as operations to act on them.

Remote Procedure Calls (or RPCs for short) by contrast, and as the name implies, are more concerned about procedures - doing things. They can be made to be entity-centric if desired; however, they need not be. For this reason, it can be simpler to implement as it doesn't require you to think about mapping your requirements onto resources and operations in the way REST does. Many RPC frameworks are also quite opinionated, further reducing the decision making and enabling rich tooling that can, for example, autogenerate client SDKs or produce documentation.

Whilst RPC style communication has existed for eons, gRPC has a particular focus and has found root in systems that require:

• Performance
• Scale
• Polyglot language support
• Multiple communication styles such as bi-directional streaming, fire-and-forget messages, and server push

Companies like Delivery Hero, Square, Netflix, Slack, Medium, and Afterpay all have made decisions to use gRPC on the basis of performance. Here is a rule (E-5) from the Delivery Hero Reliability Manifesto, that clearly shows why they've bet on gRPC:

Fun fact: the 'g' in gRPC stands for something different every release.

What is Protobuf?

If gRPC is an alternative to the REST paradigm, Protocol Buffers – or Protobuf for short – replaces the most common REST payload type: JSON.

Protocol buffers provide a language-neutral, platform-neutral, extensible mechanism for serializing structured data in a forward-compatible and backward-compatible way. It’s like JSON, except it's smaller and faster, and it generates native language bindings.

Its benefits include:

1. Being smaller and faster than many other serialisation formats
2. Built-in forward- and backward-compatibility (schema evolution)
3. Code generation tooling to create server/client SDKs

It's common for gRPC and Protobuf to be paired together, but it's important to note that they need not be used together. gRPC can work with other payload types, and Protobuf can be used with other transports and communication frameworks.

In fact, it's quite common for Protobuf to be used outside of gRPC as it turns out to be a good fit for streaming solutions such as Kafka, high-volume messaging systems, data pipelines and even as the payload for more performant HTTP systems.

The Case For Contract Testing gRPC and Protobuf

We've written about the case for contract testing gRPC and Protobuf before, but to recap, the following are ways we can break a contract with our consumers:

1. Protocol-level breaking changes
2. Handling changes to message semantics
3. Coordinating changes (forward-compatibility) and dependency management
4. Providing transport layer safety (less of an issue when Protobuf is paired with gRPC)
5. Ensuring narrow type safety (strict encodings)
6. Loss of visibility into real-world client usage
7. Optionals and defaults: a race to incomprehensible APIs

Returning to our survey, then, it's not surprising that 21% of respondents identified their top risk of poor-quality APIs being "loss of contract" and 34% were concerned about impacting other internal teams that rely on their APIs.

So how can we address some of these problems?

Introducing Contract Testing for gRPC

gRPC contract testing is made possible with the Pact Plugin Framework. Plugins enable you to extend the capabilities of Pact in order to test novel transports or content types or, in the case of gRPC/Protobuf - both!

The steps to contract testing with gRPC and Protobuf are the same as with any regular Pact test, with the only difference that we need to install a plugin to validate the new transport and content types:

1. Install the gRPC/protobuf plugin (Update: More recent versions of your tooling may automatically discover and download this for you)
2. Write a consumer test
3. Publish the contract
4. Verify your provider

Let's run through these in turn through a simple Java example: the Area Calculator.

gRPC Contract Testing Example: The Area Calculator

The Area Calculator gRPC example can receive a shape via gRPC call, and return its area. It uses Protobuf as the payload, so that we can try out contract testing with both at once. See the proto file for the full definition of the service.

The proto file has a single service method calculateOne, which these examples will be testing, and a few different-shaped requests/responses:

service Calculator {
  // RPC method we are testing
  rpc calculateOne (ShapeMessage) returns (AreaResponse) {}
}

// A polymorphic, Protobuf data type
message ShapeMessage {
  oneof shape {
    Square square = 1;
    Rectangle rectangle = 2;
    Circle circle = 3;
    Triangle triangle = 4;
    Parallelogram parallelogram = 5;
  }
}

// One of the polymorphic shapes we can calculate the area for
message Square {
  float edge_length = 1;
}

...

// Response body
message AreaResponse {
  repeated float value = 1;
}

The full project can be downloaded here.

Step 1: Install the Protobuf Plugin

Once you have installed the Pact CLI tools, you can install the plugin by its registered name (protobuf), and it will be automatically discovered and installed into the relevant location on your machine:

pact-plugin-cli -y install protobuf

Step 2: gRPC Consumer Contract Test

Now that you have the plugin installed, you can write a test for your gRPC client. Just like any other Pact test, we must set up the mock with our expectations (calculateRectangleArea with the @Pact annotation), and then test our gRPC client and ensure it worked as expected (calculateRectangleArea  with the @PactTestFor annotation).

The commented JUnit test below should look familiar to experienced Pact users with some subtle differences to accommodate the use of plugins:

/**
 * Main test class for the AreaCalculator calculate service method call.
 */
@ExtendWith(PactConsumerTestExt.class)
@PactTestFor(providerName = "area-calculator-provider", providerType = ProviderType.SYNCH_MESSAGE, pactVersion = PactSpecVersion.V4)
public class PactConsumerTest {

  /**
   * Configures the Pact interaction for the test. This will load the Protobuf plugin, which will provide all the
   * Protobuf and gRPC support to the Pact framework.
   */
  @Pact(consumer = "grpc-consumer-jvm")
  V4Pact calculateRectangleArea(PactBuilder builder) {
    return builder
      // Tell Pact we need the Protobuf plugin
      .usingPlugin("protobuf")
      // We will use a V4 synchronous message interaction for the test
      .expectsToReceive("calculate rectangle area request", "core/interaction/synchronous-message")
      // We need to pass all the details for the interaction over to the plugin
      .with(Map.of(
        // Configure the proto file, the content type and the service we expect to invoke
        "pact:proto", filePath("../proto/area_calculator.proto"),
        "pact:content-type", "application/grpc",
        "pact:proto-service", "Calculator/calculateOne",

        // Details on the request message (ShapeMessage) we will send
        "request", Map.of(
          "rectangle", Map.of(
              "length", "matching(number, 3)",
              "width", "matching(number, 4)"
          )),

        // Details on the response message we expect to get back (AreaResponse)
        "response", List.of(
            Map.of(
              "value", "matching(number, 12)"
            )
          )
      ))
      .toPact();
  }

  /**
   * Main test method. This method will receive a gRPC mock server and example request message, which we will use the
   * generated stub classes to send to the mock server. The mock server will return the AreaResponse message configured
   * from the values in the setup method above.
   */
  @Test
  @PactTestFor(pactMethod = "calculateRectangleArea")
  @MockServerConfig(implementation = MockServerImplementation.Plugin, registryEntry = "protobuf/transport/grpc")
  void calculateRectangleArea(MockServer mockServer, V4Interaction.SynchronousMessages interaction) throws InvalidProtocolBufferException {
    ManagedChannel channel = ManagedChannelBuilder.forTarget("127.0.0.1:" + mockServer.getPort())
      .usePlaintext()
      .build();
    CalculatorGrpc.CalculatorBlockingStub stub = newBlockingStub(channel);

    // Correct request
    AreaCalculator.ShapeMessage shapeMessage = AreaCalculator.ShapeMessage.parseFrom(interaction.getRequest().getContents().getValue());
    AreaCalculator.AreaResponse response = stub.calculateOne(shapeMessage);
    assertThat(response.getValue(0), equalTo(12.0F));
  }
}

This should produce a pact file in the project's build directory, if successful.

Step 3: Publish gRPC Contract

Publishing your contract is the same as any other Pact test, and we always recommend using our CLI for this job:

pact-broker publish 
  --consumer-app-version 1.0.0
  ../consumer-jvm/build/pacts/protobuf-consumer-area-calculator-provider.json

NOTE: You will need to ensure the relevant PACT_BROKER_* credentials are present in your terminal.

Publishing your contract to PactFlow, you can see the integration and contract details, as you would with any other:

Step 4: gRPC Provider Contract Test

Now that we have a contract that captures the consumer's needs, we need to ensure the provider satisfies them.

Depending on the language and toolchains you use and environment you're testing against, you might be able to run this natively in those tools (such as from within JUnit, Gradle, or Maven in JVM ecosystems), or you may choose to execute the tests externally using our CLI. In this example, we'll use the CLI as it can be used to test any language, framework or system so long as it's accessible to the verifier.

You first will need to start your gRPC service locally (preferred), or have it deployed to a test environment for testing (less preferable). Once the service is running, you can simply run the verifier, passing the details of the contract you wish to validate and the port to communicate to your running gRPC service:

gRPC/area_calculator/provider-jvm: 
❯ pact_verifier_cli -f ../consumer-jvm/build/pacts/protobuf-consumer-area-calculator-provider.json -p 37757 -l none
2022-05-02T04:29:36.636972Z  INFO main pact_verifier: Pact file requires plugins, will load those now
2022-05-02T04:29:36.638556Z  WARN tokio-runtime-worker pact_plugin_driver::metrics: 

Please note:
We are tracking this plugin load anonymously to gather important usage statistics.
To disable tracking, set the 'pact_do_not_track' environment variable to 'true'.


2022-05-02T04:29:36.873435Z  INFO                 main pact_verifier: Running provider verification for 'calculate rectangle area request'

Verifying a pact between protobuf-consumer and area-calculator-provider

  calculate rectangle area request

  Test Name: io.pact.example.grpc.consumer.PactConsumerTest.calculateRectangleArea(MockServer, SynchronousMessages)

  Given a Calculator/calculate request
      with an input .area_calculator.ShapeMessage message
      will return an output .area_calculator.AreaResponse message [OK]

👏 And there we have it. We have confirmed that our gRPC client is able to call the calculator with a Rectangle shape, and that it can receive, parse and understand the AreaResponse message.

If the provider later decided to remove the Square from the list of supported shapes, this would be a safe operation to do. If it decided to accept string-encoded numbers (for example, to encode higher-precision values), this would cause a failure as the types are incorrect.

gRPC Contract Testing Guarantees

By using contract testing, we were able to address 6 out of the 7 problems that gRPC and Protobuf introduce:

1. ✅ Protocol-level breaking changes – Relevant protocol mismatches will be caught during the contract test, because the plugin will not be able to either parse or verify the expected consumer types.
2. ✅ Handling changes to message semantics – The contract test captures the representative examples and resolves ambiguous possibilities.
3. ✅ Coordinating changes (forward-compatibility) and dependency management – Through the use of the Pact Broker and versioning, Pact can allow teams to ship safely into production with the comfort that they are compatible with their consumers.
4. ✅ Providing transport layer safety (less of an issue for gRPC) – We haven't shown this here, but if Protobuf was used over HTTP, it would gain the same level of confidence as other Pact HTTP tests, which would be covered.
5. ✅ Ensuring narrow type-safety (strict encodings) – With matchers and expressions, we can narrow the allowed sets of values during validation.
6. ✅ Loss of visibility into real-world client usage – With Pact, we get fidelity to the field type of each consumer's needs.
7. ❓ Optionals and defaults: a race to incomprehensible APIs – The "specification by example" approach Pact has improves the comprehensibility, but is currently not capable of fully resolving the dilemma.

Summary

gRPC and Protobuf are a powerful combination, allowing organisations to create large-scale, high-volume and high-performance communication systems. However, the technology opens up several possibilities for introducing breaking changes that could spell disaster for teams operating those platforms. With the introduction of the Pact Plugin Framework and the gRPC/Protobuf Plugin, Pact enables teams to apply contract testing to prevent such problems and safely evolve their system.

So, what are you waiting for? Get started with your 👉 gRPC contract testing journey, or watch the video below 👇 to see the example in this post in action.

The pact CLI tool, which is used to interact with PactFlow via the CLI, has a command named can-i-deploy. This command is used as part of application deployment to check if there has been a successful verification. This successful verification happens between existing application versions and the application version you’re about to deploy. A successful can-i-deploy check indicates that the application being deployed is compatible with the applications it integrates with, making it safe to deploy.

The can-i-deploy command may also indicate that the verification results are unknown at the time the check is performed. This indicates the verification process is still executing. Since the verification result is not yet available, we cannot tell if it's safe to deploy and the build, meaning the deployment process could fail.

Why Are The Results Unknown?

When performing consumer driven contract testing, a typical flow would include a webhook that kicks off a new provider application build when a consumer application publishes an updated pact file. This provider application build will verify the pact, which generates the result can-i-deploy needs to check. If the provider build has not finished verifying the pact when the check is performed the result is unknown.

Bi-directional contract testing makes the can-i-deploy step less dependent on the provider application build, as PactFlow can compare the updated consumer pact file with an already published OAS file. However, complex OAS and pact files take time to compare, and the results can also be unknown the first time the can-i-deploy check is called due to the speed of the automated testing pipeline. In either case, the build can be blocked.

What Can I Do To Make My CI/CD Pipeline Resilient?

1. Polling

The can-i-deploy command can be configured to poll for results. This allows the command to wait a short time and retry so that it can get the complete results rather than failing. This command works for standard contract testing AND bi-directional contract testing. By using the retry-while-unknown and retry-interval flags you can configure the number of retries to attempt and the number of seconds before each retry to suit your needs.

Factors to consider when configuring these flags:

• How long does your provider build take to perform the verification step for consumer driven contract testing?

• How large and complex is your OAS file for bi-birectional contract testing?

• How long are you willing to have your pipelines run before failing?

pact-broker can-i-deploy --pacticipant Foo \ 
                         --version 617c76e8bf05e1a480aed86a0946357c042c533c \ 
                         --to-environment production \
                         --retry-while-unknown 5 \
                         --retry-interval 3 

2. Branches and Environments

Bi-directional contract testing is not dependent on running a separate provider build to complete pact verification. Instead, PactFlow generates comparisons with the OAS files from integrated applications to verify compatibility with each version of each integrated application.

PactFlow uses branches of applications and deployed environments to determine which verification results are most likely to be required in future can-i-deploy checks. These specific verification results are then pre-generated whenever a new pact is published, allowing the can-i-deploy command to quickly access the pre-generated results in most cases.

Utilizing both strategies will improve the resilience of your CI/CD pipeline and prevent unnecessary build failure so that you can always deploy with confidence. For a more detailed breakdown on how to use the can-i-deploy CLI tool in CI/CD check out the PactFlow docs on the subject here.

Each language implementation of Pact needs to implement the rules of this specification, and advertise which version(s) are supported, corresponding closely to which features are available.

With the V4 spec, there were several major new features added:

• Support for synchronous messages, enabling request/response use cases outside of HTTP, to accompany existing support for asynchronous messaging
• Allows HTTP and non-HTTP (aka "Message Pact") interactions in a single pact file
• Support for user defined plugins, to extend the behaviour of Pact

...among a number of other quality of life improvements and matchers.

PactFlow UI Support

It's imperative that PactFlow customers receive the highest level of support for their contract testing experience, and so today we're pleased to announce that V4 pacts - including rendering markdown associated with user-defined plugins - are now supported in several languages, and contracts generated from them can be properly displayed in the PactFlow UI.

Here is a gRPC example that shows a verified contract

Notice how at the top of the contract, we can see a user-defined view of the contract:

Whilst we actually support a reasonably reach subset of Markdown, in this case, it's just a rendered protobuf using the familiar ```language code gates syntax.

Available Now

Plugins interactions and any other pact files created using version 4 of the spec are now available on all plans.

The need for SCIM API

Pactflow is loved by organisations of all sizes – from startups to major global enterprises. While Pactflow has previously supported SAML as an SSO option, SSO provisioning is only supported on demand. Additionally, with heightened awareness around security, another important use case we heard from customers is off boarding team, members. We know that all organisations, specifically large enterprises, need to tightly control who can access IT assets - including SaaS products - in order to comply with regulation and implement acceptable security controls.

Secure and automated provisioning and de-provisioning of users

We are pleased to announce support for our SCIM API to complement our SAML SSO option. SCIM is an industry standard API that IDPs implement as an extension to SAML, allowing large organisations to automate the onboarding, off boarding and management of employees to third party systems.

1. Users can be pre-provisioned into their appropriate team and with their appropriate roles
2. Users will be automatically de-provisioned in the event they leave their organisation or have the entitlements revoked (e.g. department change)
3. Any updates to the users will be reflected with the user on-demand, not during next login.

That is - the Pactflow user store will be kept in sync with their IDP of choice, such as Okta or Azure AD.

How to get started

SCIM is now available for all customers on our Enterprise Plans (both SaaS and on-premise). For existing Enterprise Plan customers on our SAML setup follow the SCIM guide (or our on-premises guide) to connect your IDP to our SCIM endpoint.

If you’re new to Pactflow or on a Starter or Team Plan, get in touch with our sales team to learn more.

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.

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

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.

• 📹 See an AMA from 2021 where Ron Holshausen took us through "What's in store for Pact specification v4.0?"
• 📙 Read the V4 spec RFC for a full list of changes: https://github.com/pact-foundation/pact-specification/issues/71
• 🚀 Implementations in Rust core and JVM has been completed
• 🌍 All our Pact specifications are open-source and you can see them all here
  

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 😲

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