Slow Tests — Find the Bug¶

Category: Testing Anti-Patterns → Slow Tests — a suite so slow the team stops running it before pushing.

This file is critical-reading practice for test speed. Each snippet is a plausible test (or fixture) in Go, Java, or Python that passes and looks reasonable — but is needlessly slow, and the slowness will compound across a suite until nobody runs it. Read each the way a reviewer who cares about feedback time would, and answer three questions:

Where is the time going? Why is it slow (which cause)? How would you make it fast without losing coverage or gaining flakiness?

The "bug" here is rarely a crash — it's a cost. A 2-second test sails through review because it's green; the problem only appears multiplied across the suite. Train your eye to see the I/O, the sleep, the per-test boot, the giant fixture before it becomes 40 minutes of CI.

How to use this file: read each snippet and write your own answer before expanding the collapsible. The skill is noticing the cost, not recalling the name.

Table of Contents¶

1. The thorough little unit test
2. Waiting for the worker
3. A fresh start every time
4. The realistic fixture
5. The thorough parametrization
6. The end-to-end calculator
7. The shared speed-up that went wrong
8. The retry that sleeps

Snippet 1 — The thorough little unit test¶

# Python — a unit test for a caching rule
import redis

def test_cache_returns_stored_value():
    r = redis.Redis(host="localhost", port=6379)   # real Redis
    cache = TtlCache(r)
    cache.set("k", "v", ttl=60)
    assert cache.get("k") == "v"
    r.flushdb()

class FakeKV:
    def __init__(self): self._d = {}
    def set(self, k, v, ttl=None): self._d[k] = v
    def get(self, k): return self._d.get(k)

def test_cache_returns_stored_value():
    cache = TtlCache(FakeKV())
    cache.set("k", "v", ttl=60)
    assert cache.get("k") == "v"

Snippet 2 — Waiting for the worker¶

// Go — verifying an async email send
func TestSignupSendsEmail(t *testing.T) {
    svc := NewSignupService(mailer)
    svc.Signup("a@b.com")
    time.Sleep(3 * time.Second) // give the worker time
    if !mailer.Sent("a@b.com") {
        t.Fatal("no email sent")
    }
}

func TestSignupSendsEmail(t *testing.T) {
    svc := NewSignupService(mailer)
    svc.Signup("a@b.com")

    deadline := time.Now().Add(3 * time.Second)
    for time.Now().Before(deadline) {
        if mailer.Sent("a@b.com") {
            return // success — milliseconds, not 3 seconds
        }
        time.Sleep(5 * time.Millisecond)
    }
    t.Fatal("no email sent within 3s")
}

Snippet 3 — A fresh start every time¶

// Java (JUnit 5) — repository tests
class OrderRepositoryTest {
    private ApplicationContext ctx;

    @BeforeEach
    void setUp() {
        ctx = SpringApplication.run(Application.class);   // boots the whole app
    }

    @Test void findsPending()  { /* uses ctx.getBean(...) */ }
    @Test void findsShipped()  { /* uses ctx.getBean(...) */ }
    @Test void findsCancelled(){ /* uses ctx.getBean(...) */ }
}

@DataJpaTest
@Transactional                         // per-test rollback keeps tests isolated on the cached context
class OrderRepositoryTest {
    @Autowired OrderRepository repo;
    @Test void findsPending()   { /* ... */ }
    @Test void findsShipped()   { /* ... */ }
    @Test void findsCancelled() { /* ... */ }
}

Snippet 4 — The realistic fixture¶

# Python — validating a discount rule
def test_gold_members_get_discount():
    db = load_production_snapshot("prod_dump_2024.sql")   # 1.2 GB, ~25 s to import
    members = MemberService(db)
    gold = members.find_one(tier="gold")
    assert members.discount_for(gold.id) == 0.20

def test_gold_members_get_discount():
    members = MemberService(FakeMembers({1: "gold"}))
    assert members.discount_for(1) == 0.20

Snippet 5 — The thorough parametrization¶

# Python — "covering all the cases"
@pytest.mark.parametrize("year",  range(2000, 2025))   # 25
@pytest.mark.parametrize("month", range(1, 13))        # 12
@pytest.mark.parametrize("day",   range(1, 29))        # 28
def test_is_weekday_runs(year, month, day):
    # 25 * 12 * 28 = 8400 cases
    assert is_weekday(year, month, day) in (True, False)

@pytest.mark.parametrize("date,expected", [
    ((2024, 6, 7),  True),   # a known Friday
    ((2024, 6, 8),  False),  # a known Saturday
    ((2024, 6, 9),  False),  # a known Sunday
    ((2024, 6, 10), True),   # a known Monday
])
def test_is_weekday(date, expected):
    assert is_weekday(*date) is expected

Snippet 6 — The end-to-end calculator¶

// Java — testing a tax calculation through the HTTP API
@SpringBootTest(webEnvironment = RANDOM_PORT)
class TaxTest {
    @Autowired TestRestTemplate rest;

    @Test
    void taxIsEightPercent() {
        var resp = rest.postForObject("/checkout",
            new Cart(List.of(new Line("sku-1", 100))), Receipt.class);   // full stack + DB
        assertEquals(8.0, resp.tax());
    }
}

class TaxCalculatorTest {
    @Test
    void taxIsEightPercent() {
        assertEquals(8.0, new TaxCalculator().tax(100.0));   // microseconds, no boot
    }
}

Snippet 7 — The shared speed-up that went wrong¶

# Python — someone made the DB tests "fast" by sharing one connection
@pytest.fixture(scope="session")
def db():
    conn = connect(start_postgres())
    apply_migrations(conn)
    yield conn                     # shared across ALL tests, no cleanup
    conn.close()

def test_count_starts_at_zero(db):
    assert db.count_orders() == 0          # passes... sometimes

def test_insert_increments_count(db):
    db.insert_order("o-1")
    assert db.count_orders() == 1

@pytest.fixture(scope="session")
def engine():                       # expensive + immutable → once
    conn = connect(start_postgres())
    apply_migrations(conn)
    yield conn
    conn.close()

@pytest.fixture
def db(engine):                     # mutable → per test, rolled back
    tx = engine.begin()
    try:
        yield engine
    finally:
        tx.rollback()               # each test starts clean → no order-coupling

def test_count_starts_at_zero(db):     assert db.count_orders() == 0
def test_insert_increments_count(db):
    db.insert_order("o-1")
    assert db.count_orders() == 1

Snippet 8 — The retry that sleeps¶

// Go — testing retry-with-backoff against a flaky dependency
func TestRetriesThreeTimes(t *testing.T) {
    dep := &flakyDep{failTimes: 2}            // fails twice, then succeeds
    client := NewClient(dep, WithBackoff(time.Second)) // 1s, 2s real backoff
    err := client.Call()                       // sleeps ~3s total during real backoff
    if err != nil {
        t.Fatalf("expected success, got %v", err)
    }
}

// Production: the client sleeps via an injected interface, not time.Sleep directly.
type sleeper interface{ Sleep(d time.Duration) }

func TestRetriesThreeTimes(t *testing.T) {
    dep := &flakyDep{failTimes: 2}
    fake := &fakeSleeper{}                      // records durations, returns instantly
    client := NewClient(dep, WithBackoff(time.Second), WithSleeper(fake))

    err := client.Call()                        // no real waiting — microseconds
    if err != nil {
        t.Fatalf("expected success, got %v", err)
    }
    if got := len(fake.slept); got != 2 {       // and we can assert the backoff happened
        t.Fatalf("expected 2 backoff sleeps, got %d", got)
    }
}

What to Train Your Eye On¶

The reviewer's reflex: when a test does I/O, waits on the clock, or boots the world, ask "what is this test actually verifying, and what's the cheapest layer that catches that bug?" The answer is almost always faster — and the speed-up should never cost coverage or isolation.

Related Topics¶

• junior.md · middle.md · senior.md · professional.md — the progression behind every fix here.
• tasks.md — fix these patterns yourself, with solutions.
• optimize.md — a full slow suite profiled and sped up with timing numbers.
• Flaky Tests — sleeps, shared state, and real time cause both slowness and flakiness.
• Mystery Guest — giant fixtures and shared data hide test inputs and slow tests down.
• Over-Mocking — the opposite hazard when faking goes too far.
• Architecture → Anti-Patterns — system structures that resist change.