Testing a full-stack app: Full-Stack Development (Expert)

Why write tests?

Every time you change the Notes app, something old can break: a fix in search can break pinning. Clicking through every screen by hand takes 20 minutes and you will skip it when you are tired. A test is code that checks your code, and it runs in seconds, every time.

Think of it like this: A car factory tests each part on its own (unit tests), then tests the engine fitted to the gearbox (integration tests), then a driver takes the finished car on a test track (end-to-end tests). There are thousands of part checks, fewer engine checks and only a few test drives, because test drives are slow and costly.

Level	What it checks	Speed	Notes app example	Common tool
Unit	One function alone	Milliseconds	validateNote rejects an empty title	Vitest, Jest
Component	One UI part with fake data	Fast	NoteForm shows "Title is required"	Testing Library
Integration	API handler + real test database	Seconds	POST /api/notes saves a row	Vitest + Supertest
End-to-end (E2E)	The whole app in a real browser	Slow	Sign up, add a note, see it in the list	Playwright

Unit tests: the base of the pyramid

javascript

import { test, expect } from 'vitest';
import { validateNote } from './validate-note.js';

test('rejects a title that is only spaces', () => {
  expect(validateNote({ title: '   ' }).ok).toBe(false);
});

test('accepts a 100-character title but not 101', () => {
  expect(validateNote({ title: 'a'.repeat(100) }).ok).toBe(true);
  expect(validateNote({ title: 'a'.repeat(101) }).ok).toBe(false);
});

Runs with Vitest in Node: pure functions such as validation and reducers are the easiest to test.

Integration tests: API plus a test database

javascript

import request from 'supertest';
import { createApp } from '../src/app.js';
import { createTestDb } from './helpers.js';

test('a user cannot delete another user\'s note', async () => {
  const db = createTestDb();            // fresh SQLite file or schema for each test
  const app = createApp(db);
  const asha = await signupAndLogin(app, 'asha@example.com');
  const ravi = await signupAndLogin(app, 'ravi@example.com');
  const created = await asha.post('/api/notes').send({ title: 'Rent' });
  const res = await ravi.delete('/api/notes/' + created.body.id);
  expect(res.status).toBe(404);
});

Runs on Node.js with Vitest and Supertest: real routes, real SQL, but a throwaway test database (never production).

Component and end-to-end tests

typescript

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { test, expect, vi } from 'vitest';
import { NoteForm } from './NoteForm';

test('shows an error and does not save an empty note', async () => {
  const onSave = vi.fn();
  render(<NoteForm onSave={onSave} />);
  await userEvent.click(screen.getByRole('button', { name: 'Save' }));
  expect(screen.getByText('Title is required')).toBeTruthy();
  expect(onSave).not.toHaveBeenCalled();
});

A component test with Testing Library: find things the way a user does (by role and label), not by CSS class.

typescript

import { test, expect } from '@playwright/test';

test('user can log in and create a note', async ({ page }) => {
  await page.goto('http://localhost:3000/login');
  await page.getByLabel('Email').fill('test-user@example.com');
  await page.getByLabel('Password').fill(process.env.E2E_PASSWORD ?? '');
  await page.getByRole('button', { name: 'Log in' }).click();
  await page.getByRole('button', { name: 'New note' }).click();
  await page.getByLabel('Title').fill('Buy milk');
  await page.getByRole('button', { name: 'Save' }).click();
  await expect(page.getByText('Buy milk')).toBeVisible();
});

An end-to-end test with Playwright, shown as an example: a real browser clicks through the running app.

What to test first

Money: prices, totals, discounts, refunds. A wrong number here costs real rupees.
Auth and permissions: signup, login, logout, and "user A cannot read, edit or delete user B's notes".
Data-loss paths: delete, edit, import and migrations. Losing a user's notes is the worst bug a notes app can have.
Every bug you fix: write a test that fails because of the bug, then fix it. This is a regression test, and the bug can never quietly come back.

Tests in CI, and flaky tests

output

# .github/workflows/test.yml
name: test
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

GitHub Actions runs every test on each push; a red cross blocks the merge.

A flaky test passes sometimes and fails sometimes with no code change. Common causes are real timers, tests that depend on each other's data, the current date, and waiting for a fixed time instead of waiting for something to appear. Fix the cause: give each test its own data, pass a fake clock, and use waits like Playwright's expect(...).toBeVisible() that retry until the element shows.

Tip: Write code that is easy to test: pass things like the database, the clock and fetch in as parameters. Then a test can pass a fake, and you do not need tricks to replace them.

Careful: Never point tests at the production database. Use a separate test database that is created and wiped by the tests. A test that deletes notes must never be able to reach real users' notes.

Testing a full-stack app

Explanation

Why write tests?

Unit tests: the base of the pyramid

Integration tests: API plus a test database

Component and end-to-end tests

What to test first

Tests in CI, and flaky tests

Watch the lesson

In real life: The fees bug that tests would have caught

Practice (0/3 done)

Quick quiz

Read more (free)