Describe testing strategies, including unit testing, integration testing, system testing and user acceptance testing

What this dot point is asking

NESA wants you to distinguish the testing strategies that operate at different scales of a system, identify their purpose, and give a concrete example of each.

The answer

The test pyramid

The conventional model: many cheap tests at the base, fewer expensive tests at the top.

Unit testing

Test one function or class in isolation. Dependencies (database, network, file system) are replaced with mocks or stubs.

# code under test
def calculate_gst(price):
    return round(price - price / 1.1, 2)

# unit test
import pytest

def test_calculate_gst_basic():
    assert calculate_gst(11.0) == 1.0

def test_calculate_gst_zero():
    assert calculate_gst(0.0) == 0.0

def test_calculate_gst_rounds_to_two_decimals():
    assert calculate_gst(10.99) == 1.0

Properties: fast, deterministic, run on every commit, locate bugs precisely.

Integration testing

Test how components work together, including real or test-instance external services (database, message queue).

def test_create_order_integration(test_db):
    # Real test database, populated with a test user
    response = client.post(
        "/api/orders",
        json={"product_id": 7, "qty": 2},
        headers={"Authorization": "Bearer test-token"},
    )
    assert response.status_code == 201
    order = test_db.execute("SELECT * FROM orders WHERE id = ?", (response.json["id"],)).fetchone()
    assert order is not None
    assert order["product_id"] == 7
    items = test_db.execute("SELECT * FROM order_items WHERE order_id = ?", (order["id"],)).fetchall()
    assert len(items) == 1

Properties: slower than unit tests (seconds), catch issues that arise at boundaries (SQL errors, contract mismatches, transaction handling).

System (end-to-end) testing

Test the whole application from outside, typically through the UI or public API, against a deployed environment.

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

test("user can complete a purchase", async ({ page }) => {
  await page.goto("/");
  await page.getByRole("button", { name: "Sign in" }).click();
  await page.getByLabel("Email").fill("test@example.com");
  await page.getByLabel("Password").fill("test-password");
  await page.getByRole("button", { name: "Log in" }).click();

  await page.getByRole("link", { name: "Mechanical keyboard" }).click();
  await page.getByRole("button", { name: "Add to cart" }).click();
  await page.getByRole("link", { name: "Checkout" }).click();
  await page.getByRole("button", { name: "Pay now" }).click();

  await expect(page.getByText("Thank you for your order")).toBeVisible();
});

Properties: slow (tens of seconds per test), flakey (real browser, real network), catch issues no other layer can.

User acceptance testing (UAT)

The product is exercised by real users (or business stakeholders standing in for them) against acceptance criteria from the original brief. Driven by humans, not automation.

A typical UAT scenario:

• Acceptance criteria: "A merchandiser can add a new promotional banner to the home page that disappears after the promotion end date."
• Tester: the head of merchandising.
• Pass criteria: they can complete the task without developer help, and the banner behaves as documented.

UAT happens after development, before release. Confirms the system meets the business needs, not just the technical specification.

Test-driven development (TDD)

Write the test first, watch it fail, write the code to make it pass, then refactor. Cycle:

1. Red: write a failing test.
2. Green: write the simplest code that passes.
3. Refactor: clean up the code while tests stay green.

TDD produces a comprehensive test suite as a side effect, encourages small focused units, and surfaces design issues early.

Other test types

• Regression testing: rerun existing tests after a change to confirm nothing was broken. Usually automated.
• Performance testing: measure response time and throughput under load.
• Security testing: SAST, DAST, penetration testing (see secure-development-lifecycle).
• Smoke testing: a quick check after deployment that the basics work.
• Property-based testing: generate random inputs and assert properties (rather than checking specific cases).

Tooling

Continuous testing

Tests run on every commit in CI. Failed tests block merging. This is what makes continuous integration work.