Testing basics: unit, integration and end-to-end: Frontend Web Development (Expert)

Why test?

Without tests, you check your site by hand: open it, click around, and hope nothing broke. That is slow, and you forget steps. A test suite checks hundreds of things in seconds. It catches bugs before users do, lets you change code without fear (refactoring), and documents what the code is supposed to do.

Think of it like this: Think of a sweet shop owner who tastes one laddoo from every new batch before the tray goes out. It takes a minute and saves a day of unhappy customers. Tests are that taste check for your code: small, quick checks every time you make a new batch, which means every change.

The test pyramid

Level	What it checks	Speed	How many
Unit	One function or component on its own	Milliseconds	Many
Integration	Several parts together, for example a form with its validation and a faked API	Fast	Some
End-to-end (E2E)	The whole app in a real browser, like a user: open the page, type, click, see the result	Seconds each	A few, for the most important journeys such as login and checkout

A unit test: Arrange, Act, Assert

javascript

// cart.js
export function cartTotal(items) {
  return items.reduce((sum, item) => sum + item.price * item.qty, 0);
}

// cart.test.js
import { describe, it, expect } from 'vitest';
import { cartTotal } from './cart.js';

describe('cartTotal', () => {
  it('adds price times quantity for every item', () => {
    // Arrange: set up the data
    const items = [{ price: 40, qty: 2 }, { price: 25, qty: 1 }];
    // Act: call the code
    const total = cartTotal(items);
    // Assert: check the result
    expect(total).toBe(105);
  });

  it('is 0 for an empty cart', () => {
    expect(cartTotal([])).toBe(0);
  });
});

describe groups tests, it is one test, expect checks a result. Run them with npx vitest.

toBe checks exact equality (like ===), good for numbers, strings and booleans.
toEqual compares the contents of objects and arrays.
toThrow checks that a function throws an error.
Jest uses almost the same describe, it and expect syntax, so the skill carries over.

Tip: Start with pure functions: they take inputs and return an output, with no DOM, network or clock. They are the easiest to test. Keep your rules (prices, validation, formatting) in pure functions and keep the DOM code thin.

Mocking: faking the network

javascript

import { it, expect, vi } from 'vitest';
import { loadUser } from './api.js';

it('returns the user name from the API', async () => {
  const fakeFetch = vi.fn().mockResolvedValue({
    ok: true,
    json: async () => ({ name: 'Asha' }),
  });
  vi.stubGlobal('fetch', fakeFetch);

  const user = await loadUser(7);

  expect(fakeFetch).toHaveBeenCalledWith('/api/users/7');
  expect(user.name).toBe('Asha');
});

A mock replaces the real fetch, so the test is fast, works offline and always gets the same answer

Testing what the user sees

Testing Library (for React, Vue, plain DOM and more) finds elements the way a user does: by role, label and visible text, not by CSS classes. A query like screen.getByRole("button", { name: "Pay" }) works only if the button really has that accessible name, so these tests also push you toward accessible HTML. Playwright goes one step further and drives real browsers.

javascript

// tests/order.spec.js
import { test, expect } from '@playwright/test';

test('user can add a dosa and see the total', async ({ page }) => {
  await page.goto('http://localhost:5173/');
  await page.getByRole('button', { name: 'Add Masala Dosa' }).click();
  await expect(page.getByText('Total: ₹80')).toBeVisible();
});

Playwright clicks through your app in Chromium, Firefox and WebKit. Run it with npx playwright test.

Run tests on every push (CI)

output

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

GitHub Actions runs your tests on a fresh computer for every push and pull request; a red cross appears if anything fails

A good test checks one behaviour and has a name that says it: "gives free delivery at 199 or more".
It covers edge cases: empty lists, 0, the exact limit, very big numbers and wrong input.
It is independent: it does not depend on other tests or on the order they run in.
It is reliable: no real network, no real clock, no random values unless you control them.
It fails when the code is wrong. A test that can never fail is worse than no test.

Careful: 100% code coverage does not mean bug-free. Coverage only shows which lines ran during the tests, not whether the checks were good. Aim for meaningful tests on the important logic.

Testing basics: unit, integration and end-to-end

Explanation

Why test?

The test pyramid

A unit test: Arrange, Act, Assert

Mocking: faking the network

Testing what the user sees

Run tests on every push (CI)

Watch the lesson

In real life: A billing app that stopped giving wrong discounts

Practice (0/3 done)

Quick quiz

Read more (free)