Instruction to Deploy Contract Test between NextJS and NestJS with Pact

Introduction

  • Contract Testing is an integration testing method focused on verifying the interaction between a Consumer (the service user) and a Provider (the service provider). Instead of testing the entire system, Contract Testing ensures that both parties adhere to a shared covenant (contract). Key benefits include: early detection of non-compatible errors between Frontend and Backend, reduction of dependency on complex staging environments and enabling API changes to be made more confidently without breaking the partner's application.
  • Pact is currently the most popular Consumer-Driven Contract Testing tool. It allows the Consumer to define expectations regarding the response from the Provider and then packages these expectations into a JSON file (Pact file). Pact's advantages lie in supporting multiple languages, automatically generating documentation based on test cases and having robust integration capabilities into CI/CD pipelines to ensure the Provider always meets the Consumer's exact requirements before deployment.

Prerequisites

This article continues to build upon previous articles, so detailed source code will not be provided. Please refer back if you need the full code.


Detail

Please install the following package into both NextJS and NestJS projects:

yarn add -D @pact-foundation/pact


When applying Contract Testing, we have two approaches:

  • Consumer-Driven Contract Testing (CDCT): meaning the Frontend (API user) initiates requirements first.
    • Why does Pact prioritize Frontend definition first?
    • Pact's philosophy is: Backend should only provide what the Frontend truly needs.
    • If the Backend defines it, it often returns excess data (e.g., returning both password_hash, internal_id which the Frontend does not use).
    • When Frontend defines it first, Backend will know exactly which fields they need to avoid "accidentally" deleting those critical fields.
  • Provider-Driven / Bi-Directional Contract Testing: if the Backend team wants to proactively define the schema first, we still have a workaround.
    • The Backend can proactively define the API schema on Swagger and the Frontend team will use that data to write contract tests, thus returning the workflow back to the beginning like CDCT.


Summarized Workflow will be as follows:

  1. The FE team as the consumer defines the API including necessary fields to be used.
  2. Run the contract test to generate the JSON file.
  3. Share this JSON file with the BE team (can be via a sub repo to avoid manual sharing).
  4. The BE team as the provider when implementing a feature only needs to ensure it passes the contract test from this JSON file.
  5. Later, before deployment, simply run the contract test again to know if changes in the code base affect the APIs in use.

Note that when running contract test on the FE side, it will not involve calling the server directly (as the BE might not even have implemented that feature yet), only the contract test run from the BE side involves actual API calling.


NextJS Project

Create test/ChatBot/contract.test.ts as follows:

import { MatchersV3, PactV3 } from "@pact-foundation/pact";
import path from "path";

const provider = new PactV3({
consumer: "NextJS-Chat-Frontend",
provider: "NestJS-AI-Backend",
dir: path.resolve(process.cwd(), "pacts"),
});

describe("Contract Test with NestJS Backend", () => {
it("returns a list of conversations", async () => {
provider
.given("conversations exist")
.uponReceiving("a request for all conversations")
.withRequest({ method: "GET", path: "/conversations" })
.willRespondWith({
status: 200,
body: MatchersV3.eachLike({
id: MatchersV3.string("1"),
name: MatchersV3.string("John Doe"),
lastMsg: MatchersV3.string("Hello"),
}),
});

await provider.executeTest(async mockService => {
const url = `${mockService.url}/conversations`;
const response = await fetch(url);
const data = await response.json();
expect(data[0].name).toBe("John Doe");
});
});
});

The code above defines a Consumer Test on the NextJS side. It uses PactV3 to initialize a contract between "NextJS-Chat-Frontend" and "NestJS-AI-Backend". In it, the given method sets the Provider state, uponReceiving describes the request purpose and withRequest defines the endpoint to call. The willRespondWith part uses Matchers to regulate the returned data type (here a list of objects where id, name, lastMsg are strings). Finally, executeTest will run a simulated server to perform actual API calling and verify if the received data matches the commitment.


When the test runs successfully, it will automatically generate the pacts/NextJS-Chat-Frontend-NestJS-AI-Backend.json file with similar content:

{
"consumer": {
"name": "NextJS-Chat-Frontend"
},
"interactions": [
{
"description": "a request for all conversations",
"providerStates": [
{
"name": "conversations exist"
}
],
"request": {
"method": "GET",
"path": "/conversations"
},
"response": {
"body": [
{
"id": "1",
"lastMsg": "Hello",
"name": "John Doe"
}
],
"headers": {
"Content-Type": "application/json"
},
"matchingRules": {
"body": {
"$": {
"combine": "AND",
"matchers": [
{
"match": "type",
"min": 1
}
]
},
"$[*].id": {
"combine": "AND",
"matchers": [
{
"match": "type"
}
]
},
"$[*].lastMsg": {
"combine": "AND",
"matchers": [
{
"match": "type"
}
]
},
"$[*].name": {
"combine": "AND",
"matchers": [
{
"match": "type"
}
]
}
}
},
"status": 200
}
}
],
"metadata": {
"pact-js": {
"version": "16.3.1"
},
"pactRust": {
"ffi": "0.5.4",
"models": "1.3.11"
},
"pactSpecification": {
"version": "3.0.0"
}
},
"provider": {
"name": "NestJS-AI-Backend"
}
}

This is the Pact (contract) file automatically generated in JSON format. It contains all the detailed information about the interactions defined in the previous step, including information about the Consumer, Provider, required request (request) and expected response (response). Specifically, the matchingRules part records data type checking rules (match by type) instead of exact values, making verification on the Provider side more flexible while ensuring the required data structure.


NestJS Project

Create test/pact-provider.spec.ts

import { INestApplication } from "@nestjs/common";
import { Test, TestingModule } from "@nestjs/testing";
import { Verifier } from "@pact-foundation/pact";
import path from "path";
import { AppModule } from "src/app.module";

describe("Pact Verification", () => {
let app: INestApplication;

beforeAll(async () => {
const moduleFixture: TestingModule = await Test.createTestingModule({
imports: [AppModule],
}).compile();

app = moduleFixture.createNestApplication();
await app.init();
await app.listen(3001);
});

afterAll(async () => {
await app.close();
});

it("should validate the expectations of NextJS-Chat-Frontend", async () => {
const verifier = new Verifier({
provider: "NestJS-AI-Backend",
providerBaseUrl: "http://localhost:3001",
pactUrls: [path.resolve(process.cwd(), "pacts/nextjs-chat-frontend-nestjs-ai-backend.json")],
stateHandlers: {
"conversations exist": async () => {
return Promise.resolve();
},
},
});

await verifier.verifyProvider();
});
});

This code performs the verification task (Verification) on the Provider (NestJS) side. First, it initializes the actual NestJS application and runs on port 3001. Then, the Verifier object is used to read the Pact file created from the Frontend. It will automatically send the simulated requests within the contract file to the running NestJS server and compare the returned results with what the Consumer expects. The stateHandlers part is usually used to initialize initial data (such as inserting data into the database) to prepare for testing; here, when nothing is defined, it only checks if the actual API request and response match the content from the pact file.


Test result when running:

$ yarn test
yarn run v1.22.22
$ jest
PASS src/app.controller.spec.ts
PASS src/test/test.controller.spec.ts
PASS src/test/pact-provider.spec.ts

Test Suites: 3 passed, 3 total
Tests: 11 passed, 11 total
Snapshots: 0 total
Time: 1.333 s, estimated 2 s
Ran all test suites.

Verifying a pact between NextJS-Chat-Frontend and NestJS-AI-Backend
a request for all conversations (3ms loading, 258ms verification)
Given conversations exist
returns a response which
has status code 200 (OK)
includes headers
"Content-Type" with value "application/json" (OK)
has a matching body (OK)
✨ Done in 1.94s.


You can modify the content of this controller/conversations.controller.ts file, for example, I delete the id field as follows:

import { Controller, Get } from "@nestjs/common";

@Controller("conversations")
export class ConversationsController {
@Get()
getConversations() {
return [
{
name: "NestJS System",
lastMsg: "Socket.io is ready",
time: "10:00",
online: true,
},
{
name: "React Squad",
lastMsg: "New components added",
time: "Yesterday",
online: false,
},
];
}
}


Result when testing again:

$ yarn test
yarn run v1.22.22
$ jest
PASS src/app.controller.spec.ts
PASS src/test/test.controller.spec.ts
FAIL src/test/pact-provider.spec.ts

● Pact Verification › should validate the expectations of NextJS-Chat-Frontend

Test Suites: 1 failed, 2 passed, 3 total
Tests: 1 failed, 10 passed, 11 total
Snapshots: 0 total
Time: 1.482 s, estimated 2 s
Ran all test suites.

Verifying a pact between NextJS-Chat-Frontend and NestJS-AI-Backend
a request for all conversations (2ms loading, 259ms verification)
Given conversations exist
returns a response which
has status code 200 (OK)
includes headers
"Content-Type" with value "application/json" (OK)
has a matching body (FAILED)

Failures:
1) Verifying a pact between NextJS-Chat-Frontend and NestJS-AI-Backend Given conversations exist - a request for all conversations
1.1) has a matching body
$[1] -> Actual map is missing the following keys: id
$[0] -> Actual map is missing the following keys: id
There were 1 pact failures
error Command failed with exit code 1.

You can see that it has reported a missing key id error accordingly. This way, before deploying in the future, you only need to run the test again to know if your changes affect the frontend team's integration.


Happy coding!

See more articles here.

Comments

Post a Comment

Popular posts from this blog

All Practice Series

Image
Introduction This is a comprehensive page about the technologies I have shared in series format. You can view brief introductions and links to directly access each series you are interested in. In the field of software development, to deploy a product from the initial idea to its release, the standard process typically involves several stages as follows: Database : Designing and implementing the database according to business requirements, storing data during the system's operation. Backend : Handling the main logic of the system, communicating with the database and services. Frontend : Building the interface for users to interact with the system, which could be a desktop, mobile, or web application. This usually includes implementing UI/UX and integrating APIs from the backend. DevOps : Deploying the system for use, which can be done on a server or in the cloud. Testing : Applying testing methods to ensure the product meets the standards for release. Of course, these are just stan...
Read more

Kubernetes Deployment for Zero Downtime

Image
Introduction In Kubernetes (K8s) , a Pod is the smallest resource unit used to run one or more containers during deployment. There are several ways to create a Pod : you can create it directly, use a ReplicationController , or a ReplicaSet . However, the most commonly used resource for managing Pods is the Deployment . When you use a Deployment , it actually creates a ReplicaSet to manage the Pods but comes with many additional benefits that support the deployment process. Some Advantages of Deployment : Ensures Pod Availability : It guarantees that the specified number of Pods are always running according to the configuration, automatically deploying additional Pods if any failures occur. Supports Restart and Undo Deployment : Allows you to easily restart or roll back to previous versions of your Deployment . Zero Downtime Deployment : When updating configurations or scaling Deployments , zero downtime is crucial. This means that new Pods are created while the old Pods are stil...
Read more

Deploying a NodeJS Server on Google Kubernetes Engine

Image
Introduction to GKE Google Kubernetes Engine (GKE) is a managed Kubernetes service provided by Google Cloud Platform , facilitating simple and efficient deployment of Docker images. We only need to provide some configuration for the number of nodes, machine types, and replicas to use. Some Concepts Cluster A Cluster is a collection of Nodes where Kubernetes can deploy applications. A cluster includes at least one Master Node and multiple Worker Nodes . The Master Node is used to manage the Worker Nodes . Node A Node is a server in the Kubernetes Cluster. Nodes can be physical servers or virtual machines. Each Node runs  Kubernetes , which is responsible for communication between the Master Node and Worker Node , as well as managing Pods and containers running on it. Pod A Pod is the smallest deployable unit in Kubernetes . Each Pod contains one or more containers, typically Docker containers. Containers in the same Pod share a network namespace, meaning they have the ...
Read more

Setting up Kubernetes Dashboard with Kind

Image
Introduction In a previous article, I guided you through using Helm to deploy on Google Kubernetes Engine . However, if you want to cut down costs by using Kubernetes in your local environment instead of relying on a cloud provider during development, then Kind is your go-to. There are several tools to help set up Kubernetes locally, such as MiniKube , Kind , K3S , KubeAdm , and more. Each tool has its own pros and cons. In this article, I'll walk you through using Kind to quickly set up a Kubernetes cluster on Docker . Kind stands out for its compactness, making Kubernetes start up quickly, being user-friendly, and supporting the latest Kubernetes versions. Working with Kind Firstly, follow the instructions here to install Kind according to your operating system. If you're using Ubuntu , execute the command: [ $( uname -m ) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.23.0/kind-linux-amd64 chmod +x ./kind sudo mv ./kind /usr/local/bin/ki...
Read more

Monitoring with cAdvisor, Prometheus and Grafana on Docker

Image
Introduction Monitoring a system is crucial after deploying a product to a production environment. Keeping an eye on system metrics like logs , CPU , RAM , disks , etc, helps identify the system's status, performance issues, and provides timely solutions to ensure stable operations. While cloud providers like Google , Amazon , or Azure offer built-in monitoring systems, if your company needs to manage multiple applications/systems/containers and desires a centralized monitoring system for easier management, using cAdvisor , Prometheus , and Grafana is a sensible choice. These three popular open-source tools are widely used by DevOps teams, especially for monitoring container applications. cAdvisor Developed by Google , cAdvisor is an open-source project used to analyze resource usage, performance, and other metrics from container applications, providing an overview of all running containers. Find more details here Prometheus Prometheus is a toolkit for system monitoring and a...
Read more

Using Kafka with Docker and NodeJS

Image
Introduction to Kafka Kafka is an open-source , distributed messaging system that functions on a publish/subscribe model. It is widely used by numerous large companies for high-performance , real-time data streaming. Developed by LinkedIn since 2011, Kafka has grown into the most popular distributed streaming platform. It can handle vast amounts of records with high efficiency. Advantages of Kafka Open-source : Freely available and continuously improved by a large community. High-throughput, high-frequency : Capable of processing large volumes of data across topics continuously. Automatic message storage : Allows for easy message retrieval and verification. Large user community : Offers extensive support and shared resources. Basic Concepts If you're new to Kafka and Message Queues, here are some key concepts to understand: Producer : Creates and sends data to the Kafka server, where data is sent as messages in byte array format. Consumer : One or more consumers subscribe to...
Read more

Practicing with Google Cloud Platform - Google Kubernetes Engine to deploy nginx

Image
Introduction This article provides simple step-by-step instructions for those who are new to Google Cloud Platform (GCP) and Google Kubernetes Engine (GKE) . I'll guide you through using  GKE  to create clusters and deploy nginx . The instructions below will primarily use gcloud  and kubectl  to initialize the cluster, which is more convenient than manual management on the Google Cloud interface. Prerequisites First, you need to prepare the following: Have a GCP account with permission to use Cloud services. If you're new, you'll get a $300 free trial to use for 90 days . Create a new GCP project. Enable Compute Engine and Kubernetes Engine services. Install Google Cloud SDK and kubectl For this installation step, refer to the GCP documentation for instructions tailored to your operating system. Once installed, execute the following commands to check if gcloud  and kubectl  are installed: gcloud version kubectl version If you see the version resul...
Read more

Kubernetes Practice Series

Image
Introduction Kubernetes (often abbreviated as K8s ) is an open-source system designed to automate the deployment, scaling, and management of containerized applications. This page serves as a collection of articles related to Kubernetes (K8s) , including theoretical concepts and practical guides on using Kubernetes to set up essential tools for the software development process. I will continue to update this series with new articles as ideas come to mind, to ensure the series becomes more comprehensive. The articles are arranged in increasing order of difficulty to make it easier for you to follow. If you have time, it's recommended that you start from the beginning of the series to acquire the necessary knowledge and information that will prepare you for the subsequent articles. Key Topics Covered in This Series Basic Knowledge : Fundamental concepts, common commands, etc. Resources : Pod, Deployment, Service, StatefulSet, Ingress, etc. Pod Autoscaler : Horizontal and Vertical sc...
Read more

Sitemap

Image
A page aggregator designed for easy reference and search, compiling all blog posts for convenient access. Loading all posts...
Read more

DevOps Practice Series

Image
Introduction DevOps is a combination of development (Dev) and operations (Ops), aimed at uniting people, processes, and technology to enhance the software development lifecycle. Here are some key aspects of DevOps: Collaboration and Communication: DevOps fosters a culture where development, IT operations, quality engineering, and security teams work together seamlessly. Continuous Integration and Continuous Delivery (CI/CD): These practices automate the integration and delivery of code changes, ensuring faster and more reliable software releases. Infrastructure as Code (IaC): This approach involves managing and provisioning computing infrastructure through machine-readable scripts, rather than physical hardware configuration. Monitoring and Logging: Continuous monitoring and logging help teams to detect issues early and maintain system reliability. Automation: Automating repetitive tasks reduces errors and increases efficiency, allowing teams to focus on more strategic work. By impleme...
Read more