Why Test? (Not the Religious Answer)

"Tests exist so you can change code without holding your breath."

The Religious Answer (Skip It)

The religious answer to "why test?" usually goes: "tests prove correctness," "TDD is the only true way," "100% coverage means quality." Every one of those is wrong, and the working engineers shipping production code know it. Tests don't prove correctness — they sample it. TDD is one workflow among several. Coverage is a lagging indicator that 100% of garbage is still garbage.

The Working-Engineer Answer

The real reason to test is this: so you can change code without holding your breath. Six months from now, you'll need to refactor that auth handler, or upgrade Next.js by two majors, or replace a library that just got abandoned. The test suite is the only thing standing between you and "did I just break something I forgot about?"

Everything else — coverage percentage, code-review check marks, even catching bugs at the moment they appear — is a side effect. The primary value is trust. A passing suite buys you the right to change things.

The Shape Every Test Takes — AAA

Arrange. Act. Assert.

Arrange the world — set up inputs, fixtures, mocks. Act on the code under test — call the function, click the button. Assert the result — check what came back, what changed, what got called.

Some tests are tiny enough that the three steps blur into one line. But the shape is still there. If a test feels chaotic, it's usually because AAA got mangled — too much arranging happens inside the act, or assertions get sprayed through the body. Pull them apart and the test reads itself.

Tests are insurance, not religion. You buy insurance because the alternative — "I'll just be careful" — doesn't survive contact with future-you at 2 a.m. Test for the same reason.

What Tests Are NOT

Tests are not proof of correctness — you can't enumerate every input. Tests are not specification — specs change, tests are commits. Tests are not documentation — mostly, though a good test name reads like one. Tests are not code review, and a green suite doesn't mean a good design.

They are: a safety net that catches the small drops, and a tripwire for the big ones. That's all. That's enough.

Code

First Vitest test, AAA shape explicit·typescript

// sum.test.ts
import { describe, it, expect } from 'vitest';
import { sum } from './sum';

describe('sum', () => {
  it('adds two numbers', () => {
    // Arrange
    const a = 2;
    const b = 3;

    // Act
    const result = sum(a, b);

    // Assert
    expect(result).toBe(5);
  });

  it('handles negative numbers', () => {
    // AAA all on one line — still AAA.
    expect(sum(-1, 1)).toBe(0);
  });
});

The function under test·typescript

// sum.ts
export function sum(a: number, b: number): number {
  return a + b;
}

Exercise

Pick a pure function you wrote recently — even a one-liner. Write three tests for it: one happy path, one edge case, one explicit failure case using expect(...).toThrow() or expect(...).not.toBe(...). Don't install Vitest yet — just write the test file as if it were installed. The point is to feel the AAA shape, not to see a green check.

Hint

If you reach for tests that 'verify React renders' or 'verify the library returns its own output,' step back. The test should verify *your* logic, not someone else's. Pick the smallest piece of yours.

Why Test? (Not the Religious Answer)

The Religious Answer (Skip It)

The Working-Engineer Answer

The Shape Every Test Takes — AAA

What Tests Are NOT

Code

External links

Exercise

Progress

Comments 0