Keeping your Mocks in check, with Pactflow + Mock-Service-Worker

mswpact.md

Keeping your Mocks in check, with Pactflow + Mock-Service-Worker

Web Service workers, you may not have heard of them but they help provide rich offline experiences, periodic background syncs, push notifications—functionality that would normally require a native applications


Now as much as I love rich web experiences, I know from first hand experience, how painful they can be to test. Thankfully the OSS community heard our collective cry and the msw.js team created Mock Service Worker

I’ll let them explain in their own words why -

By bringing the ability of Service Workers to capture requests for the purpose of caching, Mock Service Worker enables API mocking on the highest level of the network communication chain. It is the closest thing to a mocking server without having to create one.

Since Service Worker is a standard API shipped by all modern browsers. Integrating Mock Service Worker into your application, or testing setup, requires no extra configuration, but placing a worker file and declaring mocks.

I love it, no need to worry about my clients calling method, be it fetch, or axios or any other number of http request libraries in JavaScript, I can plug in something super quick and portable.

The setup guide and examples are great. Their setup guide promises you get you up and running in ten minutes, and if you know your way around a javascript app, you should be done in that time!

I hadn’t used msw before, and was keen to try it out, but didn’t have the need at the time, however I saw a proposal to integrate in with Pact - the open source contract testing tool

I love a good picking up a bit of an OSS thread, so I ran with it and am pleased to announce the release of pact-msw-adapter

This will allow you to generate Pact contract files from your existing MSW mock’s.

Now those familiar with Pact would know that in a traditional consumer driven contract flow, the provider would perform verification against its own codebase.

The act of encoding a consumer / provider pair as specification by example means that a tightly formed contract is created, which is tricky to verify without some effective tooling such as ‘matchers’ to ensure we check for schema and type compliance and ‘provider states’ to ensure we can replay the same request but generate different responses, depending on the different states of your clients application interface you are testing.

We would normally not advocate generating Pact files from BYO tools, for traditional CDC due to problems that would be caused at Provider verification time.

Fortunately the Pactflow team heard the need of teams wanting to use reap some of the benefits of contract testing, without the full investment of provider side verification.

I’ve previously written about the benefits of documenting API’s with openAPI / swagger.

Doesn’t matter when, before, during or after, but having something there, that you can verify your provider service against is a brilliant safety net.

Once you have a verified provider contract, you need two things to be really successful. You want to share that contract with your clients, and furthermore if you can also understand how your consumer use your service, you are in a significantly stronger position than before as a Provider.

Cue the launch of Bi-Directional Contract testing.

Pact has long been the de-facto for contract sharing, and provider verification.

The pact specification https://github.com/pact-foundation/pact-specification along with the swagger specification is open source, as they wanted to make deployments safer and easier to everyone.

So we have started to launch our own range on BYO consumer side testing tool adapters.

• https://www.npmjs.com/package/@pactflow/pact-msw-adapter
• https://www.npmjs.com/package/@pactflow/pact-cypress-adapter

+ more coming (NEED TO ADD THEM ^^^^)

A simple example is here https://github.com/pactflow/pact-msw-adapter/blob/HEAD/src/pactFromMswServer.msw.spec.ts

Should probably in line some code snippets

1. https://mswjs.io/docs/getting-started/install
   1. Install pact
2. https://mswjs.io/docs/getting-started/mocks
3. https://mswjs.io/docs/getting-started/mocks/rest-api
   1. Setup pact adapter
4. https://mswjs.io/docs/getting-started/integrate
   1. Add pact hooks
   2. https://mswjs.io/docs/getting-started/integrate/node
   3. https://mswjs.io/docs/getting-started/integrate/browser
5. Get pact file and upload

Add props to Juan for all his efforts, and good work with a real world use case at Pager

give credit to https://blog.clairvoyantsoft.com/service-workers-in-javascript-simple-demo-app-81efcdf2f2c4 for diagram

link to community adapters in the docs https://docs.pactflow.io/docs/bi-directional-contract-testing/consumer/#community-adapters