Contract Testing with Pact Microservices Testing Guide

Introduction

Contract Testing with Pact is an advanced microservices testing approach that ensures different services in a distributed system can communicate correctly without breaking each other. In traditional monolithic applications, testing is simpler because everything is in one place. However, in modern systems—especially microservices architectures used by companies in Karachi, Lahore, and Islamabad—services are separated and communicate through APIs. This makes integration failures more common.

Pact is a powerful tool that supports consumer-driven contracts, meaning the service that uses an API defines the expectations, and the service that provides the API verifies those expectations.

For Pakistani students learning modern software engineering, mastering contract testing is extremely valuable. Companies in Pakistan and abroad hiring backend or QA engineers expect strong knowledge of microservices testing, CI/CD pipelines, and API reliability.

By learning Pact, students like Ahmad in Lahore or Fatima in Islamabad can confidently build scalable backend systems without fear of breaking production services.

In this tutorial, you will learn how contract testing works, how Pact implements consumer-driven contracts, and how to apply it in real-world microservices systems.

Prerequisites

Before starting this contract testing tutorial, you should understand the following concepts:

• Basic knowledge of JavaScript (Node.js) or Java
• Understanding of REST APIs and HTTP methods (GET, POST, PUT, DELETE)
• Familiarity with microservices architecture
• Basic knowledge of testing frameworks like Jest, Mocha, or JUnit
• Understanding of CI/CD pipelines (optional but helpful)

If you are new to microservices, you can first read:

• Microservices Architecture Guide on theiqra.edu.pk

Core Concepts & Explanation

Consumer-Driven Contracts in Pact

In Pact testing, the consumer is the service that makes an API call, and the provider is the service that responds.

Instead of the provider defining the API contract, the consumer defines expectations such as:

• Expected request format
• Expected response structure
• Status codes

This approach ensures that the API always meets real usage requirements.

For example, imagine a student portal system in Karachi:

• Student Service (Consumer) requests student profile data
• Profile Service (Provider) returns student information

The consumer defines:

• “I expect /student/1 to return name, roll number, and department.”

If the provider changes the response structure, Pact will catch the issue before deployment.

Pact Workflow: How Contract Testing Works

The Pact workflow consists of 4 steps:

1. Consumer writes a test and defines expectations
2. Pact generates a contract file (JSON)
3. Provider reads this contract
4. Provider verifies it against actual implementation

This ensures both services stay compatible.

Pact Broker and Contract Sharing

The Pact Broker is a central repository where contracts are stored and shared between teams.

It enables:

• Version control of contracts
• Verification tracking
• CI/CD integration
• Collaboration between teams in different cities (e.g., Lahore frontend team and Karachi backend team)

In real companies, this prevents deployment issues caused by API mismatches.

Practical Code Examples

Example 1: Basic Pact Consumer Test

Below is a simple Pact consumer test using Node.js:

const { Pact } = require('@pact-foundation/pact');
const path = require('path');

const provider = new Pact({
  consumer: 'StudentPortalFrontend',
  provider: 'StudentService',
  port: 1234,
  dir: path.resolve(process.cwd(), 'pacts')
});

describe('Pact with Student API', () => {
  beforeAll(() => provider.setup());

  afterAll(() => provider.finalize());

  test('should receive student data', async () => {
    await provider.addInteraction({
      state: 'student exists',
      uponReceiving: 'a request for student data',
      withRequest: {
        method: 'GET',
        path: '/student/1'
      },
      willRespondWith: {
        status: 200,
        body: {
          id: 1,
          name: 'Ahmad',
          department: 'Computer Science'
        }
      }
    });
  });
});

Line-by-Line Explanation:

• require('@pact-foundation/pact'): Imports Pact library
• consumer: Name of frontend or consuming service
• provider: Name of backend service
• port: Local mock server port
• dir: Folder where contract files are stored
• provider.setup(): Starts mock server
• addInteraction(): Defines expected API interaction
• state: Precondition for test
• withRequest: Defines API request structure
• willRespondWith: Expected API response

This test ensures that the frontend expects a consistent API response.

Example 2: Real-World Application (E-Commerce System in Pakistan)

Imagine an e-commerce platform in Karachi similar to Daraz.

Services:

• Order Service (Consumer)
• Payment Service (Provider)

await provider.addInteraction({
  state: 'order exists and is pending payment',
  uponReceiving: 'payment confirmation request',
  withRequest: {
    method: 'POST',
    path: '/payment/confirm',
    body: {
      orderId: 101,
      amount: 5000
    }
  },
  willRespondWith: {
    status: 200,
    body: {
      status: 'success',
      message: 'Payment confirmed'
    }
  }
});

Explanation:

• The Order Service expects payment confirmation
• The Payment Service must return success status
• If Payment Service changes response format, Pact test fails
• This prevents production payment failures affecting users in Lahore or Islamabad

Common Mistakes & How to Avoid Them

Mistake 1: Ignoring Provider Verification

Many beginners only write consumer tests but forget provider verification.

Problem:

• Consumer generates contract
• Provider never checks it
• API breaks in production

Solution:
Always run provider verification tests in CI/CD pipeline:

pact.provider.verify();

This ensures backend matches contract expectations.

Mistake 2: Over-Mocking Data in Consumer Tests

Some students create unrealistic mock responses.

Problem:

• Fake data does not reflect real API
• Tests pass but production fails

Solution:
Use realistic data formats:

• Correct field names
• Realistic JSON structure
• Production-like scenarios

Practice Exercises

Exercise 1: Create a User API Contract

Problem:
Write a Pact test where a consumer requests /user/10 and expects:

• id
• username
• email

Solution:

willRespondWith: {
  status: 200,
  body: {
    id: 10,
    username: 'ali123',
    email: '[email protected]'
  }
}

Exercise 2: Payment Service Contract

Problem:
Define a contract for /payment/status endpoint.

Solution:

withRequest: {
  method: 'GET',
  path: '/payment/status/55'
},
willRespondWith: {
  status: 200,
  body: {
    status: 'completed'
  }
}

Frequently Asked Questions

What is Pact testing in microservices?

Pact testing is a contract testing tool that ensures communication between microservices works correctly. It allows the consumer to define expectations and the provider to verify them.

How is contract testing different from integration testing?

Contract testing verifies API agreements between services, while integration testing checks the full system flow. Contract testing is faster and more isolated.

What are consumer-driven contracts?

Consumer-driven contracts mean the API consumer defines the expected behavior of the provider. This ensures APIs are built based on real usage needs.

Why is Pact important for developers in Pakistan?

Pact helps Pakistani developers build reliable systems used in fintech, e-commerce, and education platforms. It reduces production errors and improves teamwork in distributed teams.

Can Pact be used in CI/CD pipelines?

Yes, Pact integrates easily with CI/CD pipelines like Jenkins, GitHub Actions, and GitLab CI to automatically verify contracts before deployment.

Summary & Key Takeaways

• Pact enables consumer-driven contract testing for microservices
• It ensures API compatibility between services
• Contracts are generated by consumers and verified by providers
• Pact Broker helps manage shared contracts in teams
• It prevents production failures in distributed systems
• Essential skill for modern backend and QA engineers

Next Steps & Related Tutorials

To deepen your understanding, explore these tutorials:

• Learn system design with Microservices Architecture
• Improve your testing skills with API Testing Fundamentals
• Understand automation in CI/CD Pipelines Guide
• Explore backend development in Node.js Backend Development

If you want, I can also convert this into:
✅ PDF lecture notes
✅ Quiz for students
✅ React interactive lesson for your website
Just tell me 👍