Pact testing verifies that your mobile app and its backend APIs agree on request and response format before either side ships a change. It's consumer-driven contract testing: your mobile app (consumer) defines what it expects from API, and backend (provider) verifies it can deliver.
If your backend team has ever renamed a field, changed a response structure, or removed an endpoint that your mobile app depended on, pact contract testing prevents that from breaking production. The contract catches mismatch in CI before it reaches users.
What is contract testing?
Contract testing checks that two services agree on how they communicate. Instead of spinning up both services and testing full integration, you test each side independently against a shared contract.
What is contract testing solving? The deployment coupling problem. Without contract testing, you need both mobile app and backend running in same environment to verify they work together. With contract testing, you verify compatibility without a shared test environment.
A pact contract is a JSON file that documents specific request-response pairs. It says: "When mobile app sends GET /orders/123, it expects a 200 response with fields: id, status, eta, and items." The backend verifies it returns exactly that.
How does pact testing work?
Pact testing has two phases: consumer tests and provider verification.
Consumer side (your mobile app or BFF):
- Write a test that defines what your app expects from API
- Pact spins up a mock server that returns expected response
- Your test runs against mock and passes
- Pact generates a contract JSON file ("pact")
Provider side (your backend API):
- Pull contract from a pact broker or shared location
- Pact replays requests from contract against your real API
- If real API returns what contract expects, verification passes
- If not, provider CI fails before deployment
This flow means mobile team defines expectations and backend team verifies them. Neither side needs other's service running during testing.
In blog: how it works for mobile API integrations, where it fits alongside other testing types and load testing, and when testing contract agreements is overkill for your team. Pact is most popular pact testing tool for this purpose, with support for JavaScript, Java, Python, Go, and Swift. Teams using playwright automation for web testing contract flows can integrate Pact on API layer alongside their existing Playwright test suites.
Which mobile APIs need contract testing?
Not every endpoint needs a pact test. Focus contract tests on APIs where a breaking change would cause most damage.
Start with auth and core transaction endpoints. These are pact contracts that catch bugs your users actually feel.
How do you write a pact test for a mobile API?
Here's an example of pact testing for a mobile app that fetches order details. Consumer side in JavaScript:
const { PactV4 } = require('@pact-foundation/pact');
const pact = new PactV4({
consumer: 'MobileApp',
provider: 'OrderService',
});
pact.addInteraction({
states: [{ description: 'order 123 exists' }],
uponReceiving: 'a request for order details',
withRequest: {
method: 'GET',
path: '/api/orders/123',
headers: { Authorization: 'Bearer test-token' },
},
willRespondWith: {
status: 200,
body: {
id: '123',
status: 'shipped',
eta: '2026-06-25T14:00:00Z',
},
},
});
This pact testing example generates a contract file that says: "The mobile app expects GET /api/orders/123 to return id, status, and eta." The backend runs this contract against its real API during provider verification.
Where does pact testing fit vs other testing types?
Contract testing doesn't replace integration tests or E2E tests. Each catches different bugs.
Contract tests run in seconds and catch format mismatches before you need expensive integration or E2E environments. They complement your other tests. They don't replace them.
The practical testing order for a mobile API change: pact tests verify contract (CI, seconds), integration tests verify data flow (staging, minutes), load tests verify performance (nightly, minutes), E2E tests verify user experience on real devices (nightly, hours).
What is Pact Broker?
The Pact Broker (or its managed version, PactFlow) stores contracts and verification results. It's central hub where consumer and provider teams share pacts.
The pact broker serves three functions:
- Stores contract files so providers can pull them during CI verification
- Tracks verification results so teams know which versions are compatible
- Powers can-i-deploy CLI tool that tells you whether a version is safe to release
For mobile teams, Pact Broker integrates into your CI pipeline. When mobile app's consumer tests pass, contract publishes to broker. When backend's provider verification passes, result publishes back. Before either side deploys, can-i-deploy checks that versions are compatible.
When is pact testing overkill?
Pact testing adds setup cost: consumer tests, provider verification, broker infrastructure, CI integration. It's worth it for some teams and overkill for others.
Pact testing is worth it when:
- Multiple mobile apps consume same backend (iOS, Android, web, partner apps)
- Backend and mobile teams deploy independently on different schedules
- Your backend has 5+ services that communicate via APIs
- Breaking API changes have caused production incidents in past
Pact testing is overkill when:
- One small team owns both mobile app and backend
- You have fewer than 3 API endpoints
- Your API changes rarely (stable, mature product)
- You already catch API issues through integration tests that run fast enough
For most mobile teams with separate frontend and backend teams and 10+ API endpoints, pact contract testing pays for itself within first quarter.
What does a real mobile team's pact testing setup look like?
DoorDash published their contract testing implementation for their mobile Backend-for-Frontend (BFF). Their setup:
- The iOS app defines consumer pact tests against mobile BFF
- Pact contracts publish to a broker after consumer tests pass
- The BFF runs provider verification against contracts in CI
- can i deploy gates release pipeline
Their key insight: mobile app team owns contract, and BFF team verifies it. This aligns responsibility with team that feels pain when API breaks.
For teams using tools like Playwright for web consumer tests or Drizz for mobile E2E validation, pact testing handles API contract layer while your E2E tool handles user experience layer. Contract testing catches "did response format change?" Drizz catches "does screen still render correctly?" Both layers protect against different failure modes.
FAQs
What is pact testing?
Pact testing is consumer-driven contract testing for APIs. The consumer (your mobile app) writes tests that define expected request-response pairs. Pact generates a contract file. The provider (your backend API) verifies it can fulfill contract. Mismatches fail in CI before reaching production.
What is difference between pact testing and integration testing?
Pact testing verifies format agreement (request structure, response fields, status codes) without both services running. Integration testing verifies data flow and business logic with both services running in a shared environment. Pact tests are faster and catch contract-level bugs. Integration tests catch logic-level bugs.
What is a pact broker?
A pact broker stores contract files and verification results in a central location. Consumer teams publish contracts after their tests pass. Provider teams pull contracts for verification. The broker also powers can-i-deploy, a CLI tool that checks version compatibility before deployment. PactFlow is managed SaaS version.
What APIs should you write pact tests for?
Prioritize authentication, core transactions (checkout, payment, booking), and push notification payloads. These are endpoints where a breaking change has most user impact. Low-priority: analytics ingestion and static content endpoints where format changes are rare or have no visible user impact.
Can you use Playwright with pact testing?
Yes. Playwright testing can drive consumer side of pact tests for web consumers. The Afsal Backer guide on Medium shows a playwright test generating pact contracts for GraphQL APIs. For mobile consumers, you'd use Pact's native iOS (Swift) or Android (JVM) libraries instead of Playwright.
When should a mobile team skip pact testing?
Skip pact testing if one small team owns both mobile and backend, your API has fewer than 3 endpoints, changes are rare, or your integration tests already run fast enough to catch contract issues. The setup cost (consumer tests + provider verification + broker) isn't justified for simple, stable APIs owned by a single team.
