Testing — what to write, what to skip

Interviewers ask "how would you test this?" to separate engineers who write tests-by-rote from engineers who reason about confidence. The answer is rarely "100% coverage."

The vocabulary, defined once

Before the pyramid, lock down the words. These get thrown around loosely, and an interviewer notices when you use them precisely.

• Test — code that runs your real code with a chosen input and checks the result. If the check passes the test is "green"; if it fails it is "red."
• Assertion — the single line in a test that states what must be true, e.g. assert result == 42. A test with no assertion proves nothing; it only proves the code did not crash.
• Unit test — exercises one small piece (a function or class) in isolation. Fast (milliseconds), so you write many.
• Integration test — exercises several pieces wired together, often with a real database or a real HTTP call. Slower, fewer, but catches the bugs that only appear where parts meet.
• End-to-end (E2E) test — drives the whole system the way a user would (a browser clicking buttons, or a full API request). Slowest and most brittle.
• Test pyramid — the recommended proportion: many unit, fewer integration, a tiny number of E2E. Explained below.
• Mock / stub / fake — three flavors of stand-in for a real dependency. A stub returns canned answers ("when asked for user 7, return this object"). A mock is a stub that also records how it was called so the test can verify the interaction. A fake is a real-but-lightweight working implementation (an in-memory database instead of Postgres). You reach for these to keep tests fast and deterministic.
• Fixture — reusable setup data or state shared across tests (a sample user, a temp folder, a seeded database) so each test starts from a known, repeatable baseline.
• Coverage — the percentage of your lines (or branches) that ran while the tests executed. It measures what got executed, not what got verified — a crucial gap, covered in the pitfalls.
• Regression — a bug in something that used to work. The main job of a test suite is to catch regressions before users do. A test written for a fixed bug is a regression test.
• Flaky test — a test that passes and fails on the same code without changes (usually timing, ordering, or randomness). Engineers say "that's a flake" or "rerun until green" (the bad habit). Toxic, because it erodes trust in the whole suite.
• Happy path — the normal success case only. "We only tested the happy path" means edge cases are missing.
• Green / red — passing / failing. "CI is green" = all checks passed.
• Smoke test — a tiny E2E on the critical flow ("can users still log in?") — run before/after deploy.
• TDD (test-driven development) — write the failing test first, then write just enough code to make it pass, then refactor. Engineers shorthand it red-green-refactor. Forces you to define the contract before the implementation.
• Property-based test — instead of one example, you state a property that must always hold (e.g. "sorting then reversing equals reverse-then-sort-descending"), and the framework throws hundreds of random inputs at it to try to break the property. Great for finding edge cases you would never think to type by hand.

A concrete test, top to bottom (AAA)

Vocabulary sticks once you see it run. Say we wrote a tiny function and want to prove it works. The Arrange / Act / Assert shape gives every test the same readable skeleton: set up the inputs, do the one thing, check the one result.

# the code under test
def apply_discount(price, percent):
    if percent < 0 or percent > 100:
        raise ValueError("percent must be 0..100")
    return round(price * (1 - percent / 100), 2)

# a unit test, written Arrange / Act / Assert
def test_applies_a_normal_discount():
    price, percent = 200, 10      # Arrange: choose the inputs
    result = apply_discount(price, percent)  # Act: call it exactly once
    assert result == 180.0            # Assert: one behavior, one check

# a second test for the error path — a separate behavior, so a separate test
def test_rejects_out_of_range_percent():
    import pytest
    with pytest.raises(ValueError):     # Assert: it must raise
        apply_discount(200, 150)        # Act: an invalid percent

Notice the two tests are split by behavior: one proves the happy path, one proves the guard. If both lived in one test and it went red, you would not instantly know which behavior broke. That is the practical reason behind "one test = one behavior."

What to test vs what to skip

The whole skill is allocating effort to where bugs hide. A quick rule: test the logic, skip the plumbing.

Two pitfalls that fail interviews