Testing

Related Skills

• Found a code smell while writing tests? → Use refactoring to fix it first
• Need to design the class structure before testing? → Use design-patterns or principles
• Adding a database migration or API endpoint? → Use schema alongside testing

Applicability Rubric

Apply when: Any condition passes

Core Principles

Integration-First Philosophy

Ensure components work together first, then verify individual component details. Unit tests are supplementary — only add them for edge cases that integration tests cannot practically cover.

TDD Cycle (Red-Green-Refactor)

┌─────────┐
│   RED   │ ← Write failing test → confirm: "Test fails because [reason]"
└────┬────┘
     ↓
┌─────────┐
│  GREEN  │ ← Write minimal code → confirm: "All tests now pass"
└────┬────┘
     ↓
┌─────────┐
│REFACTOR │ ← Improve code → confirm: "Tests still pass after refactoring"
└────┬────┘
     ↓
   (repeat)

Each phase transition requires an explicit confirmation statement. Skipping the confirmation — especially at GREEN — breaks the feedback loop that makes TDD valuable. Without "all tests pass," you cannot be sure the fix actually works.

Testing Trophy

Inspired by Kent C. Dodds' Testing Trophy — integration tests provide the best balance of confidence and cost. This replaces the traditional pyramid to reflect an integration-first approach.

        ╱╲
       ╱  ╲
      ╱ E2E╲          Few, slow, highest confidence
     ╱──────╲
    ╱          ╲
   ╱ Integration╲     Most tests live here
  ╱──────────────╲
  ╲    Unit      ╱     Few, only for edge cases
   ╲────────────╱

Test Types

Test Type Selection

TDD Phase Discipline

Each TDD phase must be explicitly confirmed before moving to the next:

The GREEN phase is not just writing the fix — you must confirm that tests pass. Without this confirmation, the cycle is incomplete and regressions can slip through unnoticed.

Verification Discipline

When you are about to implement a feature and think "let me try a one-liner to see if this approach works" or "let me check what this API returns for the edge case first" — stop. That uncertainty is a missing test case. Encode the assumption as an assertion in the test file, run the test, and let it answer.

Why ad-hoc execution is the wrong oracle

The right reflex

Wrong: Run node -e "..." / ruby -e "..." / python -c "..." to check behavior → then write code based on the result.

Right: Add a test that asserts the expected behavior → run the test → iterate until it passes.

The assertions stay in the repo as regression coverage; the shell output does not.

Exceptions

The dividing line: if the thing you want to verify is about your code's correctness, it belongs in a test.

Working with Legacy Code (No Existing Tests)

When facing code with zero test coverage, testing requires a different entry strategy than greenfield TDD.

Characterization Tests

A characterization test captures what the code currently does, not what it should do. The goal is to lock down existing behavior so you can refactor safely.

# Step 1: Call the code and observe what happens
test "characterize: payment processor charges card with 2.9% fee" do
  processor = PaymentProcessor.new
  result = processor.charge(card: valid_card, amount: 100.0)
  # Record whatever the code actually returns
  assert_equal 102.90, result.total_charged
  assert_equal "approved", result.status
end

Dealing with Untestable Code

Legacy code often has barriers to testing. Common patterns and workarounds:

Legacy Code Testing Strategy

1. Write characterization tests first — capture current behavior with integration-level tests
2. Identify seams — find points where you can alter behavior without editing the code (subclass, extract method, wrap)
3. Make the change — add new feature or fix bug using TDD
4. Verify no regressions — all characterization tests still pass

Test Structure (AAA Pattern)

test("should calculate total with discount", () => {
  // Arrange - Set up test data
  const cart = new Cart();
  cart.addItem({ price: 100 });

  // Act - Execute the behavior
  const total = cart.calculateTotal(0.1); // 10% discount

  // Assert - Verify the result
  expect(total).toBe(90);
});

For simple validation tests (e.g., assert_raises, single-expression assertions), the AAA structure may be implicit — forcing explicit comments on a one-liner adds noise rather than clarity. AAA is most valuable when the test has meaningful setup or multi-step actions.

Completion Rubric

Before Writing Tests

Writing Tests

Test Quality

After Writing Tests

Test Naming Convention

Pattern: should [expected behavior] when [condition]

Examples:

• should return empty array when no items exist
• should throw error when input is invalid
• should calculate discount when coupon is applied

Common Test Smells

Test Double Decision Table

Before choosing a test double, check whether the test environment already provides the real dependency or a faithful simulation. Prefer real over fake, fake over stub, stub over mock — the closer to production behavior, the more confidence the test provides.

Environment-Aware Decision Flow

When to Use Test Doubles

Boundary Testing

Converted and distributed by TomeVault — claim your Tome and manage your conversions.