Self-Validating

Tests should have a boolean output

“Tests should have a boolean output. Either they pass or fail. You should not have to read through a log file to tell if the tests passed.” – Robert C. Martin

Part of the F.I.R.S.T. principles.

When to use

Always.

Why it matters

  • Automation: CI pipelines need a generic Way (Exit Code 0 or 1) to know if the build failed. They can’t read your console logs.
  • Speed: You don’t want to manually verify “Did the output string match expected?” for 1000 tests.

Signs of Violation

  • Tests that just print console.log("Result was: ", result) and require a human to check if it’s correct.
  • Tests that throw an error but catch it and just log “Error occurred” without failing the test runner.

Explanation

Problem

Manual interpretation of test results scales poorly.

Solution

Use Assertions (expect(a).toBe(b)). The test runner (Jest/PHPUnit) handles the reporting. Green or Red.

Real world analogy

Traffic Light. It’s either Red or Green. Imagine if the traffic light just printed a complex report on traffic density and let every driver decide if they should stop or go.

Pros and Cons

Pros Cons
  • CI/CD compatibility
  • No ambiguity
    		•
  • None
    		•

    Comparison

    • Manual Testing: The opposite of self-validating.

    Code example

    Typescript

    Bad (Violation)

    Good (Adherence)

    PHP

    Bad (Violation)

    Good (Adherence)