Fast

Unit tests should run quickly

“Tests must be fast. If they are slow, you won’t run them often.” – Robert C. Martin

Part of the F.I.R.S.T. principles for Unit Testing.

When to use

Writing Unit Tests.

Why it matters

  • Feedback Loop: If tests take 5 minutes, developers will not run them before every commit. If they take 0.1s, they will run them on every save.
  • Velocity: Slow tests kill momentum.

Signs of Violation

  • Tests touching the filesystem, database, or network (Integration tests masquerading as Unit tests).
  • sleep() calls in tests.

Explanation

Problem

Integration tests are valuable but slow. Unit tests must be instant to support TDD / Refactoring.

Solution

Mock everything slow. Mock the DB, mock the network, mock the file system. Test logic, not IO.

Real world analogy

Spellchecker. It checks words instantly as you type (Fast). If it had to call the Oxford Dictionary Headquarters for every word, you’d turn it off.

Pros and Cons

Pros Cons
  • Instant feedback
    		•
  • Mocks might not behave exactly like real dependencies
    		•

    Comparison

    • Integration Tests: Slower, rely on real components.
    • E2E Tests: Slowest, rely on browser/full stack.

    Code example

    Typescript

    Bad (Violation)

    Good (Adherence)

    PHP

    Bad (Violation)

    Good (Adherence)