--- name: pact-db5cf14a221f description: >- Sets up consumer-driven contract testing with Pact JS: a consumer test that writes a pact file, a provider verification that replays it, and a Pact Broker or PactFlow with can-i-deploy in CI. Use when the user mentions "pact", "contract testing", "consumer-driven contracts", "provider verification", "can-i-deploy", "Pact Broker" or wants to stop two services breaking each other without end-to-end tests. license: Apache-2.0 compatibility: "Node.js 22+ (required by @pact-foundation/pact 17), Jest or Vitest, an HTTP provider reachable from the test runner; a Pact Broker or PactFlow account for sharing contracts" metadata: author: terminal-skills version: "2.0.0" category: development tags: "contract-testing, pact, microservices, api-testing, ci" --- # Pact Contract Testing (Pact JS) ## Overview A contract test answers one question: will this consumer keep working against that provider, without starting both? The consumer test runs the real client code against a Pact mock server, and what the client sent and expected is saved as a pact file. The provider later replays that file against its real API. If both sides pass, the contract holds. A broker stores the pacts and verification results, and `can-i-deploy` uses them to decide whether a version may ship. Pact JS 17 (verified with 17.1.4) uses the V4 consumer API (`PactV4`) and the `Verifier` class. Matching rules come from `MatchersV3`. Use it for HTTP/JSON services owned by different teams or deployed independently. Do not use it for third-party APIs you cannot ask to verify, for load or latency checks, or as a replacement for testing business logic inside the provider. ## Instructions ### 1. Ask and look up first Ask only what the project cannot tell you: which service is the consumer, which is the provider, whether a broker exists (URL, token in an environment variable), and how the provider is started in tests. Look up the HTTP client the consumer uses, its test runner, the provider framework, and the CI system. Decide the names once. Consumer and provider names become part of the pact file name and the broker, so use the deployable service names (`storefront-web`, `parcel-tracker`), not team names. ### 2. Install ```bash npm install --save-dev @pact-foundation/pact vitest ``` Node 22 or newer is required. Pact files are written to `./pacts` unless `dir` says otherwise; add `pacts/` to `.gitignore` when a broker is used. ### 3. Write the consumer test Cover only what the consumer really reads. Every extra field in the expectation becomes a demand on the provider. ```js import path from 'node:path'; import { describe, it, expect } from 'vitest'; import { PactV4, MatchersV3 } from '@pact-foundation/pact'; import { ShipmentClient } from '../src/shipment-client.js'; const { like, regex, eachLike, timestamp } = MatchersV3; const pact = new PactV4({ consumer: 'storefront-web', provider: 'parcel-tracker', dir: path.resolve(process.cwd(), 'pacts'), }); describe('parcel-tracker contract', () => { it('returns a parcel that exists', () => pact .addInteraction() .given('parcel TRK-48213 is in transit') .uponReceiving('a request for parcel TRK-48213') .withRequest('GET', '/parcels/TRK-48213', (b) => b.headers({ Accept: 'application/json', Authorization: regex(/^Bearer .+$/, 'Bearer tok-7f3a'), }), ) .willRespondWith(200, (b) => b.headers({ 'Content-Type': 'application/json' }).jsonBody({ trackingCode: 'TRK-48213', status: regex(/^(label_created|in_transit|delivered)$/, 'in_transit'), updatedAt: timestamp("yyyy-MM-dd'T'HH:mm:ss'Z'", '2026-10-12T09:30:00Z'), events: eachLike({ city: like('Rotterdam'), code: like('ARR') }), }), ) .executeTest(async (mockServer) => { const client = new ShipmentClient(mockServer.url, 'tok-7f3a'); const parcel = await client.getParcel('TRK-48213'); expect(parcel.status).toBe('in_transit'); })); }); ``` Rules that keep contracts honest: - The client under test must take its base URL from a parameter, so the test can pass `mockServer.url`. - `.given(...)` names a provider state. Write it as a sentence the provider team can implement ("parcel TRK-48213 is in transit"). - Use matchers (`like`, `regex`, `eachLike`, `timestamp`) for values that vary; exact values for things the consumer branches on. - Add one interaction per distinct response the consumer handles: success, not found, validation error, unauthorized. - The mock server verifies the request too. If the client sends something different, `executeTest` throws. After `vitest run`, `pacts/storefront-web-parcel-tracker.json` exists. Open it once and check that matching rules appear under `matchingRules` and that no secret is in it (use a fake token). ### 4. Verify on the provider side Run the real provider with its dependencies stubbed, and map each provider state to setup code. ```js import { describe, it } from 'vitest'; import { Verifier } from '@pact-foundation/pact'; import { buildApp, parcelStore } from '../src/app.js'; describe('parcel-tracker provider verification', () => { it('honours every consumer pact', async () => { const server = buildApp().listen(0); const { port } = server.address(); try { await new Verifier({ provider: 'parcel-tracker', providerBaseUrl: `http://127.0.0.1:${port}`, pactUrls: ['./pacts/storefront-web-parcel-tracker.json'], stateHandlers: { 'parcel TRK-48213 is in transit': async () => { await parcelStore.reset(); await parcelStore.insert({ trackingCode: 'TRK-48213', status: 'in_transit' }); }, 'no parcel TRK-00000 exists': async () => parcelStore.reset(), }, }).verifyProvider(); } finally { server.close(); } }); }); ``` `verifyProvider()` rejects when any interaction fails, so the test fails with the diff. Missing state handlers are the most common cause of confusing failures. Use `beforeEach`/`afterEach` hooks or `requestFilter` only when every request needs shared setup such as an auth header. ### 5. Share pacts through a broker Self-hosted Pact Broker and PactFlow expose the same API. Keep the URL and token in `PACT_BROKER_BASE_URL` and `PACT_BROKER_TOKEN`; never commit them. Publish from the consumer pipeline with the Pact CLI (installed from the `pactfoundation/pact-cli` image or the `@pact-foundation/pact-cli` package): ```bash pact-broker publish ./pacts \ --consumer-app-version "$GITHUB_SHA" \ --branch "$GITHUB_REF_NAME" ``` Tell the provider to fetch from the broker and report back: ```js await new Verifier({ provider: 'parcel-tracker', providerBaseUrl: `http://127.0.0.1:${port}`, pactBrokerUrl: process.env.PACT_BROKER_BASE_URL, pactBrokerToken: process.env.PACT_BROKER_TOKEN, consumerVersionSelectors: [ { mainBranch: true }, { deployedOrReleased: true }, ], enablePending: true, providerVersion: process.env.GITHUB_SHA, providerVersionBranch: process.env.GITHUB_REF_NAME, publishVerificationResult: process.env.CI === 'true', stateHandlers, }).verifyProvider(); ``` - Selectors keep verification to the pacts that matter: the consumer's main branch and whatever is live. - `enablePending: true` stops a brand-new consumer expectation from breaking the provider build before the provider has had a chance to implement it. - Publish verification results only from CI, never from a laptop. ### 6. Gate deployments Register environments once (`production`, `staging`) in the broker. Before each deploy, ask: ```bash pact-broker can-i-deploy --pacticipant storefront-web --version "$GITHUB_SHA" --to-environment production ``` Exit code 0 means every pact involving this version is verified against what runs in that environment. After a successful deploy, record it so later checks know what is live: ```bash pact-broker record-deployment --pacticipant storefront-web --version "$GITHUB_SHA" --environment production ``` A provider-side change to the API goes through the same gate: the provider build verifies the consumers' pacts, publishes results, then asks `can-i-deploy` for itself. ### 7. Handle a provider webhook (optional) When a consumer publishes a changed pact, the broker can trigger the provider's pipeline with a webhook on the event `contract_requiring_verification_published`. This verifies the new contract at once rather than at the provider's next commit. ## Examples ### Example 1: first contract between two services Request: "storefront-web calls parcel-tracker; add contract tests." Look up `src/shipment-client.js` and the Express app of `parcel-tracker`. Add the consumer test from step 3 with a success and a 404 interaction, run `npx vitest run`, and confirm `pacts/storefront-web-parcel-tracker.json` lists both. Add the provider verification from step 4 with a state handler for each `given`. Run it against the local file. Result: two tests pass on the consumer, one verification on the provider, and no broker needed yet. ### Example 2: provider renames a field `parcel-tracker` wants to rename `status` to `state`. The provider verification fails with `Expected 'status' but it was missing` for storefront-web. The team does not rename in place: they return both fields for a release, storefront-web switches to `state` and its pact is republished, then the provider removes `status` once `can-i-deploy` shows no deployed consumer reads it. The contract turned a breaking change into a planned migration. ### Example 3: CI for the consumer (GitHub Actions) ```yaml name: storefront-web contracts on: [push] jobs: contract: runs-on: ubuntu-latest env: PACT_BROKER_BASE_URL: ${{ vars.PACT_BROKER_BASE_URL }} PACT_BROKER_TOKEN: ${{ secrets.PACT_BROKER_TOKEN }} steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: 22 } - run: npm ci && npx vitest run test/shipment-client.pact.test.js - run: > docker run --rm -v "$PWD/pacts:/pacts" -e PACT_BROKER_BASE_URL -e PACT_BROKER_TOKEN pactfoundation/pact-cli publish /pacts --consumer-app-version "$GITHUB_SHA" --branch "$GITHUB_REF_NAME" - run: > docker run --rm -e PACT_BROKER_BASE_URL -e PACT_BROKER_TOKEN pactfoundation/pact-cli broker can-i-deploy --pacticipant storefront-web --version "$GITHUB_SHA" --to-environment production ``` ## Guidelines - A pact describes what the consumer uses, not the provider's whole API. Do not copy the OpenAPI schema into it. - Do not put business rules into provider states. A state sets up data; the tests do not check the logic behind it. - Match shapes, not values, unless the consumer depends on the value. Overly exact pacts make every provider change look breaking. - Keep tokens, real customer data and production URLs out of pact files; they are uploaded and read by other teams. - Provider state names are an agreement between teams. Renaming one is a breaking change. - Messages (queues, events) use the same ideas with `MessageConsumerPact`/`MessageProviderPact`; handle them separately from HTTP. - Contract tests do not replace one or two end-to-end smoke tests, and they do not cover non-functional behaviour. - Pin the major version of the Pact packages in all services; consumers and providers on different spec versions can still interoperate, but upgrades are easier together. --- Source attribution: TerminalSkills Original project: https://github.com/TerminalSkills/skills/blob/3bfbf7f76459d89422eddc0e5f572ad0e6c393c9/skills/pact/SKILL.md License: Apache-2.0 License information: https://www.apache.org/licenses/LICENSE-2.0 Original upstream instructions; downloaded from Mega AI Hub. ## Upstream license notice Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to the Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by the Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding any notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS Copyright 2025 Terminal Skills Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. # Mega AI Hub resource metadata Creator / publisher: TerminalSkills Original project: https://github.com/TerminalSkills/skills/blob/3bfbf7f76459d89422eddc0e5f572ad0e6c393c9/skills/pact/SKILL.md Attribution basis: Source repository record Fields of work: Development & Engineering, Product Management Roles: Backend Developer, DevOps / SRE, Product Manager, QA / Test Engineer, Technical Product Manager Specialties: API, Testing Tools: Pact, Pact Broker Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: 5cf8b022c20bbf4bc8ffd304c30815656cb5e729ea87f4c6f0567f773fe43172