Eager Test

Checking too much functionality in one test.

“A test that verifies too much functionality at once.” – Gerard Meszaros

Tests that try to validate the world.

Signs of Use (Symptoms)

  • Test names are generic (testProcess).
  • One test method has 10+ assertions checking different things.
  • If the test fails, you don’t know why without debugging.

Why it is bad (Consequences)

  • Fragility: Unrelated changes break the test.
  • Obscurity: Hard to see what behavior is actually being tested.
  • Masking: If assertion 1 fails, assertions 2-10 never run.

Why it happens (Root Cause)

Laziness. “I already have the setup, let me just check X, Y, and Z too.”

When it might be okay (Exceptions)

  • Smoke tests / End-to-End tests (where setup cost is massive).

Explanation

Problem

testUserFlow creates a user, checks the name, checks the email, makes an order, checks the order status, checks the inventory…

The Flaw

It documents nothing specific. It’s a “story”, not a specification.

Real world analogy

A car inspection checklist that just says “Check Car”. If it fails, you don’t know if it’s the brakes or the lights.

Refactoring Solution

  • Split Test: Break into single-condition tests.
  • One Assertion Per Test (Conceptually).

Pros and Cons (of the Antipattern)

Pros (Why people do it) Cons (The price you pay)
  • Fast to write
    		•
  • Hard to debug
  • Assertion roulette
    		•

    Comparison

    • Related Antipatterns: Assertion Roulette, General Fixture.
    • Related Principles: SIP (Single Inspection Principle).

    Code example

    Typescript

    Bad (The Antipattern)

    Good (The Fix)

    PHP

    Bad (The Antipattern)

    Good (The Fix)