🗂️ Testing Types and Methodologies

The Testing Landscape

In the previous lesson you learned the principles of testing. Now we'll survey the types. It helps to organize them along a few independent axes: what a test verifies (functional vs non-functional), when it runs (by stage), and how much the tester knows about the internals (by approach). A real strategy mixes all three.

Functional Testing

Functional testing validates that the software behaves per its specification. It's usually organized by scope, from the smallest unit up to the whole system.

Unit testing

Verifies a single function or class in isolation. Here's a form-field validator tested thoroughly with modern Vitest (the syntax is identical in Jest):

// validateField.js
export function validateField(value, rules = {}) {
  if (rules.required && (!value || value.trim() === '')) {
    return { valid: false, error: 'This field is required' };
  }
  if (rules.minLength && value.length < rules.minLength) {
    return { valid: false, error: `Must be at least ${rules.minLength} characters` };
  }
  if (rules.maxLength && value.length > rules.maxLength) {
    return { valid: false, error: `Cannot exceed ${rules.maxLength} characters` };
  }
  if (rules.email && !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value)) {
    return { valid: false, error: 'Please enter a valid email address' };
  }
  return { valid: true, error: null };
}

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

describe('validateField', () => {
  it('flags an empty required field', () => {
    expect(validateField('', { required: true })).toEqual({
      valid: false, error: 'This field is required',
    });
  });

  it('enforces a minimum length', () => {
    expect(validateField('abc', { minLength: 5 }).valid).toBe(false);
    expect(validateField('abcdef', { minLength: 5 }).valid).toBe(true);
  });

  it('validates email format', () => {
    expect(validateField('nope', { email: true }).valid).toBe(false);
    expect(validateField('a@b.com', { email: true }).valid).toBe(true);
  });

  it('reports the first failing rule when several apply', () => {
    const rules = { required: true, minLength: 5, email: true };
    expect(validateField('', rules).error).toBe('This field is required');
    expect(validateField('a@b', rules).error).toContain('at least 5');
  });
});

💡 Factory quality control: unit testing is checking each car part — engine, brakes, transmission — before assembly. Catch a faulty part on the bench and you never have to diagnose it inside a finished vehicle.

Integration testing

Verifies that units cooperate — the seams between modules, where bugs love to hide. Here a real database is used but the email provider is mocked:

import { describe, it, expect, beforeEach, afterEach, vi } from 'vitest';
import { UserService } from '../src/UserService.js';
import { DatabaseClient } from '../src/DatabaseClient.js';

describe('user registration integration', () => {
  let userService, emailService, db;

  beforeEach(() => {
    db = new DatabaseClient(testDbConfig);
    emailService = { sendWelcomeEmail: vi.fn().mockResolvedValue(true) };
    userService = new UserService(db, emailService);
  });

  afterEach(async () => {
    await db.collection('users').deleteMany({ email: 'test@example.com' });
    await db.disconnect();
  });

  it('creates the user and sends a welcome email', async () => {
    const data = { name: 'Test User', email: 'test@example.com', password: 'secret123' };
    const result = await userService.registerUser(data);

    const saved = await db.collection('users').findOne({ email: data.email });
    expect(saved).not.toBeNull();
    expect(saved.password).not.toBe(data.password); // must be hashed
    expect(emailService.sendWelcomeEmail).toHaveBeenCalledWith(
      expect.objectContaining({ email: data.email })
    );
    expect(result.success).toBe(true);
  });

  it('rejects a duplicate email', async () => {
    await userService.registerUser({ name: 'A', email: 'test@example.com', password: 'p1' });
    const result = await userService.registerUser({ name: 'B', email: 'test@example.com', password: 'p2' });

    expect(result.success).toBe(false);
    expect(result.error).toBe('Email already registered');
    expect(emailService.sendWelcomeEmail).toHaveBeenCalledTimes(1);
  });
});

System testing

Evaluates the complete, integrated application against its requirements — usually in a production-like environment. If unit tests check the parts and integration tests check the connections, system testing is the full test drive of the assembled car on real roads.

Acceptance testing

Determines whether the software meets business needs and is ready to deliver. Variants include User Acceptance Testing (UAT), Business Acceptance Testing, and Operational Acceptance Testing (backups, recovery, monitoring). Acceptance tests are often expressed in plain-language Gherkin so non-developers can read them:

Feature: User Registration
  As a website visitor
  I want to register for an account
  So that I can access member-only content

  Scenario: Successful registration
    Given I am on the registration page
    When I enter valid registration details
    And I submit the registration form
    Then I should see a welcome message
    And I should receive a confirmation email

Those steps are then automated. A modern, browser-based implementation with Playwright is far cleaner than the older Selenium style:

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

test('a visitor can register successfully', async ({ page }) => {
  await page.goto('/register');

  const email = `test.${Date.now()}@example.com`;
  await page.getByLabel('Name').fill('Test User');
  await page.getByLabel('Email').fill(email);
  await page.getByLabel('Password', { exact: true }).fill('SecurePass123!');
  await page.getByLabel('Confirm password').fill('SecurePass123!');
  await page.getByRole('button', { name: 'Register' }).click();

  await expect(page.getByText(/welcome, test user/i)).toBeVisible();
});

Non-Functional Testing

Non-functional testing measures qualities beyond raw behavior — the difference between a feature that works and one that works well.

Performance testing

Measures responsiveness and stability under load. It has several flavors — load, stress, endurance (soak), spike, and scalability testing.

A load test with k6 ramps virtual users up and asserts on latency and error thresholds:

// load-test.js
import http from 'k6/http';
import { sleep, check } from 'k6';

export const options = {
  stages: [
    { duration: '1m', target: 50 },   // ramp to 50 users
    { duration: '3m', target: 50 },   // hold
    { duration: '1m', target: 100 },  // ramp to 100
    { duration: '5m', target: 100 },  // hold
    { duration: '1m', target: 0 },    // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% of requests under 500ms
    http_req_failed: ['rate<0.01'],   // under 1% failures
  },
};

export default function () {
  const res = http.get('https://example.com/products?search=laptop');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'responds under 500ms': (r) => r.timings.duration < 500,
  });
  sleep(2);
}

Key metrics to watch: response time, throughput, error rate, concurrent users, and resource utilization (CPU, memory).

Security testing

Hunts for vulnerabilities an attacker could exploit. It spans vulnerability scanning, penetration testing, dependency auditing, and secure code review.

Usability testing

Evaluates how intuitive the product feels, usually by watching real users attempt real tasks and measuring completion rates and errors.

💡 Restaurant critics: usability testing isn't checking the kitchen's hygiene (functional) or the building's structure (security). It's asking whether the meal was a pleasure — clear menu, prompt service, good experience.

Accessibility testing

Ensures people with disabilities can use the app, guided by the WCAG standard. A quick checklist:

• Meaningful alt text on informative images
• Color contrast meets WCAG AA
• Every interactive element is keyboard-reachable
• Form fields have associated labels
• Proper heading hierarchy and landmark structure
• No content flashes at seizure-inducing rates

Automate the low-hanging fruit with tools like axe-core or Lighthouse — they catch a large share of common issues in seconds.

Compatibility testing

Confirms the app works across browsers (Chrome, Firefox, Safari, Edge), devices (desktop, tablet, phone), and operating systems. Playwright can run the same suite across multiple browser engines out of the box.

Testing by Stage

Some testing is defined by when in the release cycle it happens.

💡 Regression = home maintenance: remodel the kitchen and you still check that the upstairs shower and the fuse box work. Changing one part of an app can quietly break another; regression tests are the walk-through that catches it.

Testing by Approach

Approaches describe how much the tester knows about the internals, and whether code runs at all.

Static vs dynamic

A code review is the classic static test — a peer examines the diff for correctness, security, maintainability, error handling, and adequate test coverage before it merges.

White box, black box, gray box

• White box: full knowledge of the code. Tests target internal structure and aim for coverage metrics — statement, branch, path, and function coverage.
• Black box: no knowledge of internals. Tests are driven by specifications using techniques like equivalence partitioning, boundary value analysis, and state transition testing.
• Gray box: partial knowledge — common for integration and penetration testing.

Statement coverage and branch coverage are not the same thing. This example reaches 100% statements with one test but needs three for full branch coverage:

function processPayment(amount, balance) {
  if (amount <= 0) return { success: false, message: 'Invalid amount' };   // branch 1
  if (amount > balance) return { success: false, message: 'Insufficient funds' }; // branch 2
  return { success: true, newBalance: balance - amount };
}

// Full branch coverage needs all three paths:
it('accepts a valid payment', () => {
  expect(processPayment(50, 100)).toEqual({ success: true, newBalance: 50 });
});
it('rejects a non-positive amount', () => {
  expect(processPayment(-10, 100).message).toBe('Invalid amount');
});
it('rejects an overdraft', () => {
  expect(processPayment(150, 100).message).toBe('Insufficient funds');
});

💡 Home inspection: a white box tester is the builder with the blueprints who knows what's behind every wall; a black box tester is the buyer who only tries the lights and taps; a gray box tester is the inspector with a moisture meter and general know-how but no full blueprints.

Continuous Testing

Continuous testing runs your automated tests at every stage of the delivery pipeline, so problems are caught within minutes of a commit rather than days later.

A trimmed, modern GitHub Actions workflow wiring the first few stages together:

name: CI

on:
  push:
    branches: [main, develop]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - run: npx playwright install --with-deps
      - run: npm run test:e2e

Hands-on Exercise

Summary & Quiz

📚 Further Reading

• Playwright — end-to-end testing docs
• k6 — performance testing docs
• Atlassian — testing in CI/CD

🚀 What's Next?

You've seen the whole map of test types. Next we zoom into one powerful methodology — Test-Driven Development — and learn the Red-Green-Refactor rhythm that lets tests drive your design.