Skip to main content

· One min read

If you use Pact and would like to support us in realising our vision of transforming the way teams test and release distributed systems, we have recently released Pactflow - our fully managed Pact Broker with additional features to simplify teams getting started and scaling with Pact and contract testing.

Read our launch announcement for more background as to why and how this all came about. It's just the start, but we're really excited about the future.

If you're hosting your own broker, or are looking to set one up, you can get started quickly and for free on our Developer Plan.

We hope to see you soon!

· 3 min read

REST is dead, long live REST

GraphQL is being hailed by many as the new REST - it has type safety, a neat DSL and a great ecosystem. Perhaps best of all, it focuses on the needs of the client; consumers get the data they want, in the shape they want it - nothing more and nothing less.

I can now fetch data from my BFF via my React Component with caching, error handling and state management all taken care of for me, just like so:

import { Query } from "react-apollo";
import gql from "graphql-tag";

const ExchangeRates = () => (
  <Query
    query={gql`
      {
        rates(currency: "USD") {
          currency
          rate
        }
      }
    `}
  >
    {({ loading, error, data }) => {
      if (loading) return <p>Loading...</p>;
      if (error) return <p>Error :(</p>;

      return data.rates.map(({ currency, rate }) => (
        <div key={currency}>
          <p>{`${currency}: ${rate}`}</p>
        </div>
      ));
    }}
  </Query>
);

For some, however, this ability to define a schema and even generate client code, harkens back to the brittle and dark ages of WSDL, whereby clients are tightly coupled to their API implementation.

Can we have our cake and it it too?

 

If you look under the covers, it turns out GraphQL is actually just a simple abstraction over REST, which means we can still test GraphQL as we do with regular RESTful APIs - including using contract testing! 🙌

GraphQL (mostly) follows just a few simple rules:

  1. Requests are made via an HTTP POST
  2. GraphQL queries are sent as stringified JSON contained within a query property of the request
  3. The response body is wrapped in the data sub-property, namespaced by the operation (Query or Mutation) that is being called, alongside any errors for the operation.

Read more about the GraphQL specification here

Constructing a basic cURL for a simplistic hello operation looks something like this:

curl -X POST \
  -H 'content-type: application/json' \
  -d '{ "query": "{ hello }" }' \
  http://someapi/api

Whilst you can create this request using the usual Pact DSL, in our latest version of Pact JS (6.x.x or @prerelease) we have even created a GraphQLInteraction interface to simplify creating the expectations - including variables support and matching rules:

  const graphqlQuery = new GraphQLInteraction()
    .uponReceiving("a hello request")
    .withQuery(`{ hello(person: $person }`)
    .withRequest({
      path: "/graphql",
      method: "POST",
    })
    .withVariables({
      person: "Sally",
    })
    .willRespondWith({
      status: 200,
      headers: {
        "Content-Type": "application/json; charset=utf-8",
      },
      body: {
        data: {
          hello: like("Hello Sally"),
        },
      },
    });

So there it is, Pact + GraphQL: a match made in heaven.

· 2 min read

If you're using Travis CI, Code Climate, or one of many other CI tools with Github, you've probably noticed the little checklist of items that shows just above the "merge" button when you open a pull request.

commit-statuses

These are called commit "statuses", and there is a Github API for reporting these (Gitlab also has a similar API). If you are using a git sha for the consumer version number when you publish your pacts, you can now use Pact Broker webhooks to report the verification statuses of your pacts back to Github.

To do this, open up your Pact Broker API Browser, and click on the NON-GET button next to the pb:webhooks relation. Modify the JSON below to match your consumer, repository and Github auth details (we recommend you make a separate token for this purpose with the repo:status grant), and click Make Request.

{
  "consumer": {
    "name": "<consumer name>"
  },
  "events": [
    {
      "name": "contract_published"
    },
    {
      "name": "provider_verification_published"
    }
  ],
  "request": {
    "method": "POST",
    "url": "https://api.github.com/repos/<organization>/<project>/statuses/${pactbroker.consumerVersionNumber}",
    "headers": {
      "Content-Type": "application/json"
    },
    "body": {
      "state": "${pactbroker.githubVerificationStatus}",
      "description": "Pact Verification Tests ${pactbroker.providerVersionTags}",
      "context": "${pactbroker.providerName}",
      "target_url": "${pactbroker.verificationResultUrl}"
    },
    "username": "USERNAME",
    "password": "PASSWORD"
  }
}

If all your consumer names match their repository names in Github, you can make this a global webhook by removing the consumer node, and replacing the hardcoded <project> name in the URL with the parameter ${pactbroker.consumerName}.

Want to use this cool feature? You'll need version 2.47.1 or later of the Pact Broker.

Check out the webhook template library for more handy webhooks.

· 2 min read

The can-i-deploy tool is a CLI that ensures you are safe to deploy a consumer or provider into a given environment. To do this, it queries the Pact Broker to ensure that there is a successful verification result between the existing application versions and the application version you're about to deploy.

If you deploy to a test environment as part of your build pipeline, you may find yourself in the situation where the verification result is unknown because the provider build is still running. What typically would happen is that a changed pact would trigger a provider build via a webhook in the Pact Broker, and the provider may not have finished before can-i-deploy is invoked.

To help out in this scenario, you can now use the following two options to let the can-i-deploy command poll until all the verification results arrive.

[--retry-while-unknown=TIMES] 
              # The number of times to retry while there is an unknown
              # verification result 
              # (ie. the provider verification is likely still running)
              # Default: 0
[--retry-interval=SECONDS]
              # The time between retries in seconds. 
              # Use in conjuction with --retry-while-unknown
              # Default: 10

Remember, however, that changes to pacts are best introduced on feature branches of your consumer. This allows your pact to be "pre-verified" by the time the branch is merged into master, which will mean can-i-deploy should never block your master build.

You can read about how to do this in The steps to reaching Pact Nirvana.

Want to use this new feature? You'll need version 1.48.0 or later of the Pact CLI, and version 2.23.4 or later of the Pact Broker

· One min read

Pact is a tool for implementing "consumer driven contracts" - a technique for testing integrations without using traditional integration tests. It was first written at realestate.com.au to help a team of developers escape the integration test hell of a rapidly expanding HTTP microservices network, and has since grown to become an open source project for contract testing in multiple languages and protocols.

Since its creation in 2013, Pact has come a long way. We're always adding new features in response to the feedback we get from our users and our own experience, but recently we've realised that we've done a poor job of letting everyone know about the awesome new things we've added along the way.

So, we've started docs.pact.io/blog as a place to let everyone know about new features in Pact, to share people's Pact experiences (good and bad!), and to help build a community of Pact users who can help each other. If you haven't already, please join us at slack.pact.io, and if you'd like to contribute a post to our blog, chat to us on the #blog channel.