Process of applying TDD to a NextJS project

Introduction

Test-Driven Development (TDD) is an advanced software development methodology where tests are written before the actual source code is implemented. This process operates in a repetitive cycle: Red (Write a failing test) -> Green (Write the minimum source code to make the test pass) -> Refactor (Optimize the code structure).

Advantages:

  • Improve source code quality: Minimize potential bugs right from the initial development phase.
  • Better system design: Thinking about testing first helps you build highly modular, loosely coupled and easy-to-maintain modules.
  • Confident Refactoring: You can comfortably improve and optimize code without fear of breaking existing features, thanks to the automated test system protection.
  • Living documentation: Test cases act as precise specification documentation, helping team members clearly understand how the system operates.
  • Reduce Debugging Time: TDD helps detect errors right at the moment "just finished typing". The cost of fixing a bug right after writing is many times cheaper than fixing it when it has reached the Staging or Production environment.

QnA

The following are some issues you might wonder about when applying TDD and the corresponding solutions

When should you use TDD?

Handling complex core business logic

  • If you are writing a tax or insurance premium calculation module, or an e-commerce pricing engine with dozens of nested conditions, coding everything and then testing will make it easy to miss edge cases.
  • TDD allows you to list all cases (Input A -> Output B) as test cases, then fill in the code. It ensures every corner of the logic is verified.

Refactoring sensitive legacy code

  • When you take over an important module but the code is too messy (Spaghetti code) and needs to be converted to a new architecture (for example, from Class-based to Hooks, or from Monolith to Microservices).
  • At this point, you will need to write tests for the inputs and outputs of the old module to lock its behavior. Then you rewrite the new code completely. If the old test suite still passes, you have successfully refactored without changing features.

Building Open Source Libraries or Shared Packages

  • If you are building shared libraries for the team (such as a UI Kit, a set of Utils, or a wrapper for an API).
  • Because many people or teams share the library, applying TDD helps shape the API Design extremely well. Because you have to build tests first, which means following the Consumer-First direction before implementing details, this will help you check in advance whether the provided interface is easy to use before wasting effort implementing the details inside, helping optimize Developer Experience (DX) from the very first line of code.

When should you not use TDD?

Although very powerful, TDD was not born for every project, so please consider it for the following cases

  • Making Prototype/POC (Proof of Concept): When this is just a small project for experimental purposes with requirements constantly changing, writing tests first will slow down the deployment speed.

  • UI/UX is too complex: Testing CSS, animations, or drag-and-drop interactions with TDD usually takes more effort than the effectiveness it brings. With UI testing, sometimes applying manual or visual tests is more effective.

Here, it is necessary to distinguish between two concepts

  • UI Appearance: Applying TDD purely to UI can lead to the following issues
    • Fragility: Just changing a CSS class or changing from a <div> tag to a <section> tag can make the test fail, even though the functionality remains unchanged.
    • High maintenance cost: Interface is the thing that changes the most based on feedback from the Designer/Product Owner. Writing tests first for every pixel will make you lose more time to fix tests every time you change colors for components.
    • Difficult to simulate with code: It is very difficult to write a test to describe CSS effects like animation/transition, box-shadow precisely.
  • UI Logic: Can be used to test the following components
    • Custom Hooks: To write tests for pure UI logic (like useCart, useAuth)
    • Utilities & Helpers: Currency formatting functions, time processing.
    • API Routes & Server Actions: This is an important logic part related to integration.
    • In addition, it can also be applied to test Conditional Rendering, Form Validation, Data Mapping.

Level of application into the project?

In a real project environment, applying TDD 100% to every corner often leads to burnout. You should make a choice and allocate according to the 80/20 rule flexibly as follows:

Prioritize TDD for (High ROI):

  • Core Business Logic: Things related to money, user data, security (e.g., payment, salary calculation, authorization).
  • Shared functions (Utilities): If the date format function fails, the whole system will fail. TDD here is mandatory.
  • Old bugs: Whenever there is a bug, write a test simulating that bug first, then fix the code (this is called Regression TDD).

Can skip TDD for (Low ROI):

  • UI/UX/Styling: Testing the color of a component with TDD takes a lot of effort but brings little benefit.
  • Simple third-party integration: If you use a third-party library that has been thoroughly tested, you do not necessarily have to TDD that library again.
  • Configuration (Config): The .env files, config files do not need TDD.

Does TDD require any specific type of test?

There is no specific requirement for a type of test when deploying TDD, but usually, to apply TDD most effectively, you can start from Integration Test, then drill down to Unit Test for complex logic parts.

Should you write each test case one by one or multiple test cases at the same time?

Uncle Bob Martin authored the Three Rules of TDD, which is enough to get started with TDD:

  • You are not allowed to write any production code unless it is to make a failing unit test pass.
  • You are not allowed to write any more of a unit test than is sufficient to fail, and compilation failures are failures.
  • You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

  • This means you should write each test one by one, which will help you focus absolutely. When you have to write 5-10 test cases at the same time, you will create multiple issues simultaneously and get easily confused when implementing code to satisfy all of them.
  • The standard process will be as follows: Write test case 1 -> Code for Pass -> Write test case 2 -> Code for Pass -> Continue with each subsequent case.

Effectiveness of TDD?

Based on the document Realizing quality improvement through test driven development: results and experiences of four industrial teams, this is the largest-scale study on TDD conducted among development teams at Microsoft and IBM.

  • Quality Results: The defect density of teams using TDD (Test-Driven Development) is 40% to 90% lower than teams using TLD (Test-Last Development).
  • Performance Results (Time/Effort): The development time of TDD teams increases by about 15% to 35%.
  • This means you will have to spend about 20% more time initially to write tests, but in return, you reduce almost double the number of bugs on Production.
  • This study indicates that TDD helps code have higher Modularity because programmers are forced to write easy-to-test code. This indirectly reduces maintenance costs in the long term.

Thus, if applied correctly, TDD will bring outstanding efficiency in the long run compared to TLD, specifically as follows:

TDD

  • Bug Density: Low (due to covering all edge cases from the beginning).
  • Initial Dev Time: Slower.
  • Maintenance Cost: Low (clean code, easy to refactor).
  • Design Quality: Good (Low coupling, High cohesion).
  • Dev Psychology: Confident, less pressure when deploying.

TLD

  • Bug Density: Higher (easy to miss sub-cases due to lack of necessary tests).
  • Initial Dev Time: Faster (because focusing on output immediately).
  • Maintenance Cost: High (hesitant to fix for fear of breaking parts without tests).
  • Design Quality: Tight coupling.
  • Dev Psychology: Anxious, spending a lot of time debugging at the end of the sprint.

Prerequisites

  • In this article, I will focus on the TDD process to deploy tests, so I will not talk in detail about how to set up testing environments, here I use NextJS, Vitest and MSW for integration testing, you can look through previous articles to know the necessary setup steps or use similar frameworks or tools.
  • I use Vitest because its superior performance will help you have an extremely fast feedback loop so that when writing tests and implementing, you will see results quickly.

Detail

First, let's create the file test/Login/integration.test.tsx to write a test for the first feature, which is a successful login.

import LoginPage from '@/app/feature/login/page'
import {
  cleanup,
  fireEvent,
  render,
  screen,
  waitFor,
} from '@testing-library/react'
import {message} from 'antd'
import {http, HttpResponse} from 'msw'
import {setupServer} from 'msw/node'
import {useRouter} from 'next/navigation'
import {
  afterAll,
  afterEach,
  beforeAll,
  beforeEach,
  describe,
  expect,
  it,
  vi,
} from 'vitest'

vi.mock('next/navigation', () => ({
  useRouter: vi.fn(),
}))

const server = setupServer(
  http.post('/api/login', () => {
    return HttpResponse.json({success: true}, {status: 200})
  })
)

beforeAll(() => server.listen())
afterEach(() => server.resetHandlers())
afterAll(() => server.close())
afterEach(() => cleanup())

vi.mock('antd', async importOriginal => {
  const actual: any = await importOriginal()
  return {
    ...actual,
    message: {
      success: vi.fn(),
      error: vi.fn(),
    },
  }
})

describe('Login Functionality', () => {
  beforeEach(() => {
    vi.clearAllMocks()
  })

  it('should redirect to home on successful login', async () => {
    const push = vi.fn()
    vi.mocked(useRouter).mockReturnValue({push} as any)

    render(<LoginPage />)

    fireEvent.change(screen.getByTestId('login-email-input'), {
      target: {value: 'test@example.com'},
    })
    fireEvent.change(screen.getByTestId('login-password-input'), {
      target: {value: 'password123'},
    })

    fireEvent.click(screen.getByTestId('login-submit-button'))

    await waitFor(() => {
      expect(push).toHaveBeenCalledWith('/home')
    })
  })
})

The above code sets up an integration test using Vitest, React Testing Library and MSW for the login feature. Specifically:

  • Uses vi.mock to simulate (mock) the useRouter hook from the next/navigation library and the message component from antd.
  • Initializes a mock server with MSW (setupServer) to intercept the POST /api/login request to always return a 200 status and a successful result.
  • Manages the lifecycle of the mock server through beforeAll, afterEach, afterAll functions and cleans up the DOM with cleanup.
  • In test case CASE 1, the code renders LoginPage, simulates user behavior entering email and password into the corresponding inputs via the data-testid attribute, then clicks the submit button and finally checks if the router's push function is called to redirect the user to the /home page.

After that, you start writing code for the file app/login/page.tsx to pass the test above.

'use client'

import {LockOutlined, UserOutlined} from '@ant-design/icons'
import {Button, Card, Form, Input, message} from 'antd'
import {useRouter} from 'next/navigation'
import {useState} from 'react'

export default function LoginPage() {
  const [loading, setLoading] = useState(false)
  const router = useRouter()

  async function handleSubmit(values: any) {
    setLoading(true)
    try {
      const res = await fetch('/api/login', {
        method: 'POST',
        headers: {'Content-Type': 'application/json'},
        body: JSON.stringify(values),
      })
      if (res.ok) {
        message.success('Login successful!')
        router.push('/home')
      }
    } finally {
      setLoading(false)
    }
  }

  return (
    <div className="flex min-h-screen items-center justify-center bg-slate-50 p-4">
      <Card className="w-full max-w-md shadow-md rounded-lg">
        <div className="text-center mb-6">
          <h1 className="text-2xl font-bold text-slate-800">Form Login</h1>
          <p className="text-slate-500 text-sm mt-1">
            Please sign in to your account
          </p>
        </div>

        <Form
          name="login_form"
          layout="vertical"
          onFinish={handleSubmit}
          autoComplete="off"
          requiredMark={false}
        >
          <Form.Item
            name="email"
            label="Email"
            rules={[
              {required: true, message: 'Please input your email!'},
              {type: 'email', message: 'Please enter a valid email!'},
          ]}
          >
            <Input
              prefix={<UserOutlined className="text-slate-400" />}
              placeholder="example@domain.com"
              className="py-2"
              data-testid="login-email-input"
            />
          </Form.Item>

          <Form.Item
            name="password"
            label="Password"
            rules={[{required: true, message: 'Please input your your password!'}]}
          >
            <Input.Password
              prefix={<LockOutlined className="text-slate-400" />}
              placeholder="••••••••"
              className="py-2"
              data-testid="login-password-input"
            />
          </Form.Item>

          <Form.Item className="mb-0 mt-6">
            <Button
              type="primary"
              htmlType="submit"
              className="w-full bg-blue-600 h-10 text-base font-medium"
              loading={loading}
              data-testid="login-submit-button"
            >
              Sign In
            </Button>
          </Form.Item>
        </Form>
      </Card>
    </div>
  )
}

This code defines a Client Component in Next.js which is the login page interface:

  • The component renders a Form consisting of two main input fields: Email and Password, along with a "Sign In" button.
  • The Input and Button elements are all attached with the data-testid attribute (e.g., login-email-input, login-password-input, login-submit-button) serving directly for identifying elements in testing files.
  • When the Form is filled validly and submitted, the handleSubmit function will be triggered: performing a call to the API endpoint /api/login using the POST method sending along user data as JSON. If the response from the API is successful (res.ok), the system will navigate the user to the home page /home using router.push.

Next, let's write the test scenario for the case where the user fails to log in due to entering the wrong password.

it('should show error message and not redirect when password is wrong', async () => {
  server.use(
    http.post('/api/login', () => {
      return HttpResponse.json(
        {success: false, message: 'Invalid credentials'},
        {status: 401}
      )
    })
  )

  const push = vi.fn()
  vi.mocked(useRouter).mockReturnValue({push} as any)

  render(<LoginPage />)

  fireEvent.change(screen.getByTestId('login-email-input'), {
    target: {value: 'test@example.com'},
  })
  fireEvent.change(screen.getByTestId('login-password-input'), {
    target: {value: 'wrong_password'},
  })

  fireEvent.click(screen.getByTestId('login-submit-button'))

  await waitFor(() => {
    expect(message.error).toHaveBeenCalledWith('Invalid credentials')

    expect(push).not.toHaveBeenCalled()
  })
})
  • Uses server.use to reconfigure the response of the API /api/login locally for this test case alone, forcing it to return an HTTP 401 Unauthorized error code along with an error message.
  • When the user enters the wrong username and password
  • Check if the application calls the function to display the error message message.error with the exact content 'Invalid credentials'.
  • Check and ensure that the router's redirect method push is not called at all, meaning the user remains on the login page.

You just need to modify the handleSubmit function to handle the above test case, simply adding a case and catching errors for the failure scenario.

async function handleSubmit(values: any) {
  setLoading(true)
  try {
    const res = await fetch('/api/login', {
      method: 'POST',
      headers: {'Content-Type': 'application/json'},
      body: JSON.stringify(values),
    })

    if (res.ok) {
      message.success('Login successful!')
      router.push('/home')
    } else {
      message.error('Invalid credentials')
    }
  } catch (error) {
    message.error('Something went wrong')
  } finally {
    setLoading(false)
  }
}

The test run results are as follows:

yarn test:vi

 ✓ test/Login/integration.test.tsx (2 tests) 177ms
   ✓ Login Functionality (2)
     ✓ should redirect to home on successful login 145ms
     ✓ should show error message and not redirect when password is wrong 30ms

 Test Files  1 passed (1)
       Tests  2 passed (2)
    Start at  19:40:56
    Duration  2.75s

 PASS  Waiting for file changes...
       press h to show help, press q to quit

I only make a sample of 2 cases like that, you can implement the remaining test cases yourselves as follows:

  • Leaving mandatory fields blank (Required Fields)
  • Incorrect email format (Format Validation)
  • System encounters an issue (500 Internal Server Error)
  • Processing status (Loading State)

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