Testing

/

Introduction

Testing saves the day
Three heroes: Unit, Integration, E2E
Fits into CI/CD

Testing

/

Unit Testing - Tiny Titans

Tests one piece in isolation
Example: Formatting a post’s date

    // utils/date.ts
export function formatDate(date: Date): string {
  return date.toLocaleDateString("en-US", { 
    month: "long", day: "numeric", year: "numeric" 
  });
}

// tests/date.test.ts
import { describe, it, expect } from "vitest";
import { formatDate } from "../utils/date";

describe("formatDate", () => {
  it("formats a valid date", () => {
    const date = new Date("2025-04-07");
    expect(formatDate(date)).toBe("April 7, 2025");
  });
});

Let's explore our first type of test: The Unit Test.

Unit tests zoom in on a single function or component, like a magnifying glass. They’re fast and catch bugs in the smallest bits of our blogging app.

Let's take a look at an example. We test a formatDate function to ensure posts show dates like “April 7, 2025” correctly. You can run these while writing code to fix logic errors instantly.

This is the formatDate function in the date ts file that we will be tesing.

We are using the Vitest framework, which shares a very similar API with other unit testing frameworks such as Jest, Jasmine or Mocha.

We import the function that we wish to test. This function becomes the unit we are testing.

"Describe" function describes the unit tests. Most often, you specify what is the unit that you are testing.

The "it" function describes and specifies individual unit tests. Each "it" function should test a specific functionality or test case. Unit tests typically include multiple "it" functions. While we only observe one test, we can easily expand it to evaluate different international date variants.

Finally, within the "it" function, we present the body of the test, which utilises an assertion library to evaluate the unit. In this instance, we employ the "expect" library, which offers assertions in natural language, such as toBe or toBeHigherThan.

Testing

/

Integration Testing - Team Work

Tests pieces together
Example: Post list with API

    // components/PostList.tsx
import { useEffect, useState } from "react";
import { formatDate } from "../utils/date";

export function PostList() {
  const [posts, setPosts] = useState<{ title: string; date: Date }[]>([]);
  useEffect(() => {
    fetch("/api/posts")
      .then((res) => res.json())
      .then((data) => setPosts(data.map((p: any) => ({ ...p, date: new Date(p.date) }))));
  }, []);
  return (
    <div>{posts.map((p) => <div key={p.title}>{p.title} - {formatDate(p.date)}</div>)}</div>
  );
}

// tests/PostList.test.tsx
import { render, screen } from "@testing-library/react";
import { describe, it, expect, vi } from "vitest";
import { PostList } from "../components/PostList";

describe("PostList", () => {
  it("fetches and renders posts", async () => {
    vi.spyOn(global, "fetch").mockResolvedValue({
      json: () => Promise.resolve([{ title: "Test Post", date: "2025-04-07" }]),
    } as any);
    render(<PostList />);
    expect(
      await screen.findByText("Test Post - April 7, 2025")
    ).toBeDefined();
  });
});

Let's talk about integration tests, where multiple teams have to work together.

Integration tests check how components collaborate, like fetching posts and showing them in our app.

In this integration test, we’ll mock an API and test if posts render properly in a list. Mocking replaces the original functionality with a custom implementation. You run integration tests after connecting parts together to ensure they play nice. They are still very fast, similar to unit tests.

This is the component that we are testing.

It uses fetch function to get data from our backend ...

... and uses the formatDate function we tested earlier.

Integration tests share the same structure as unit tests with "describe" and "it" functions.

We use Vitest's mocking mechanism to fake the response of the fetch function, providing our data. For mocking approaches, please check Vitest documentation.

Next, we utilise the render function from the React Testing Library to render the component, which will invoke this mocked fetch function and display the result.

Lastly, we utilise the screen from the React Testing Library, which enables us to find items based on various selectors, such as searching for a specific text. At this stage, we are not concerned with the rendered elements; we are only focused on ensuring that an expected text is displayed to the user.

Testing

/

E2E Testing - Full Adventure

Tests the whole app
Example: Browsing and adding postsI

    // tests/e2e/blog.spec.ts
import { test, expect } from "@playwright/test";

test("user views and admin adds post", async ({ page }) => {
  await page.goto("http://localhost:3000");
  await expect(page.getByText("Test Post")).toBeVisible();

  await page.goto("http://localhost:3000/admin");
  await page.fill("#title", "New Post");
  await page.fill("#date", "2025-04-08");
  await page.click("button[type='submit']");
  await page.goto("http://localhost:3000");
  await expect(page.getByText("New Post")).toBeVisible();
});

Testing

/

Which one?

Test Type	Description	Speed	CI/CD When to Execute
Unit	Tests one piece in isolation (e.g., formatDate )	Lightning fast (ms)	Every commit
Integration	Tests multiple pieces together (e.g., fetch + render)	Moderate (100s of ms)	Pull requests
End-to-End (E2E)	Tests the full app like a user (e.g., browsing posts)	Slow (seconds)	Before deployment

So, when should you write and execute these thests?

Unit tests are the base—tons of them, super quick, testing small bits like formatDate. In CI/CD, run unit tests on every code push—fast feedback keeps bugs out early. Use unit tests for quick checks on functions and components—its's your first line of defense.

You will need fewer integration tests to check connections, like API to UI, with moderate speed. In CI/CD, execute unit tests on pull requests, ensuring features work together before merging. Integration tests ensure data moves smoothly between parts—this is vital for app cohesion.

E2E tests are the tip—slow but thorough, ensuring the whole app works. In CI/CD E2E tests run last, green-lighting deployment when the app’s fully functional. You tie them into CI/CD for a bulletproof dev process!

Testing

/

Case Study

Problem: Posts don’t show
Check Unit Tests ✅
Test fetch + render ✅
E2E Fails ❌

Full Stack Development

Introduction to Testing

Testing

Introduction

Testing

Unit Testing - Tiny Titans

Testing

Integration Testing - Team Work

Testing

E2E Testing - Full Adventure

Testing

Which one?

Testing

Case Study