Testing Vocabulary

• Distinguish static vs dynamic testing.
• Distinguish black-box vs white-box testing.
• Define smoke, regression, sanity, and acceptance tests.
• Tell positive (happy-path) from negative (error-path) tests.

WHEN do you test?      static (without running) vs dynamic (by running)
HOW MUCH do you see?   black-box (just inputs/outputs) vs white-box (the code)
WHY this run?          smoke / sanity / regression / acceptance
WHAT path?             positive (valid input) vs negative (invalid input)

Static vs dynamic

static    examine code WITHOUT running it
          → code review, linting (ruff), type checking (mypy)
dynamic   examine code BY running it
          → unit tests, integration tests, manual testing

Both matter. Static analysis (Lessons 41-44) catches whole classes of bugs before the code ever runs.

Black-box vs white-box

black-box   test only inputs → outputs; ignore the internal code
            "given 10 and 20, the average should be 15"
white-box   test with knowledge of the internals
            "make sure BOTH branches of this if-statement run"

Positive vs negative tests

# positive (happy path): valid input → correct output
assert divide(10, 2) == 5

# negative (error path): invalid input → correct error
try:
    divide(10, 0)
    assert False, "should have raised"
except ZeroDivisionError:
    pass    # good — it raised as expected

Beginners only write positive tests. Professionals write negative ones too — most real bugs hide on the error paths.

Test purposes

smoke test    quick "does it even start?" check before deeper testing
sanity test   quick check that a specific fix works
regression    re-run old tests to ensure new changes broke nothing
acceptance    does it meet the user's/business's requirements?

A few more you'll meet

unit test       tests one small piece (a function/class) in isolation
integration     tests pieces working together
test fixture    the setup data/state a test needs
test double     a stand-in for a real thing (mock, stub, fake)
flaky test      a test that sometimes passes, sometimes fails — fix it!

For a login function, here are four tests. Label each on every dimension:

Test A: "correct username + password → logged in"
        → dynamic, black-box, positive, (acceptance-ish)

Test B: "wrong password → 'invalid credentials' error"
        → dynamic, black-box, negative

Test C: "the password-hashing branch runs for new users"
        → dynamic, white-box (we know the internal branch)

Test D: mypy flags that password is typed str, not bytes
        → static (no code is run)

# the same login, tested both ways
def login(user, pwd, db):
    record = db.get(user)
    if record is None:
        raise ValueError("unknown user")
    if record["pwd"] != pwd:
        raise ValueError("invalid credentials")
    return "logged in"

db = {"aisyah": {"pwd": "secret"}}

# positive
assert login("aisyah", "secret", db) == "logged in"

# negative (two error paths)
for bad in [("aisyah", "wrong"), ("ghost", "x")]:
    try:
        login(*bad, db)
        assert False, "should have raised"
    except ValueError:
        pass
print("all login checks passed ✅")

Read the diff

One small function, four kinds of test. The positive test proves it works; the two negative tests prove it fails correctly; a static check (mypy) would catch type mistakes without running anything. Good test suites cover all of these — not just the happy path.

Testing terms are dimensions, not rivals. Static (no run) vs dynamic (run). Black-box (outputs only) vs white-box (knows the code). Positive (valid input) vs negative (invalid input). Purposes: smoke, sanity, regression, acceptance. Speak these fluently — the PCET exam and every QA conversation use them. Next: the levels of testing.