Designing for Testability — Optimize & Reconcile¶

Testable design buys decoupling, fast feedback, and deterministic tests — and the recurring worry is that it costs runtime performance. It almost never does. Interface dispatch is a single-digit-nanosecond concern that the JIT or escape analysis usually erases; DI containers cost startup time, not steady-state throughput; and the real performance story runs the other direction — a testable design is what turns an 8-minute integration suite into a 40-second unit suite. This file reconciles the two. For each scenario: the design choice, the measurement (concrete numbers), and the principled resolution. The rule throughout: testable design is nearly free at runtime; optimize the rare measured hot-path indirection only, and never trade away suite speed to chase a nanosecond.

Table of Contents¶

1. Scenario 1 — Interface dispatch vs concrete call in a hot loop (Go)
2. Scenario 2 — Spring reflection startup vs compile-time DI (Java)
3. Scenario 3 — Pure functional core tests in microseconds (Python)
4. Scenario 4 — In-memory fake vs Testcontainers: 8 min → 40 s (Go)
5. Scenario 5 — The Humble Object keeps the slow boundary out of the fast suite (Java)
6. Scenario 6 — A seam adds an allocation in a hot path (Go)
7. Scenario 7 — Over-mocking costs nothing at runtime but rots the suite (Python)
8. Scenario 8 — Fake clock removes sleep-based flakiness and wall-clock waste (Go)
9. Scenario 9 — interface{} / dynamic dispatch defeats JIT monomorphism (Java)
10. Scenario 10 — God constructor does I/O, so every test pays for it (Python)
11. Scenario 11 — Function injection vs struct-of-interfaces in a tight path (Go)
12. Scenario 12 — Test parallelism unlocked by removing global state (Java)
13. Scenario 13 — unittest.mock import & patch overhead at collection time (Python)
14. Rules of Thumb
15. Related Topics

Scenario 1 — Interface dispatch vs concrete call in a hot loop (Go)¶

You introduce an interface so the dependency can be faked in tests. A reviewer objects: "interface calls are slower than concrete calls — this is in a loop that runs millions of times."

type Hasher interface {
    Sum(b []byte) uint64
}

type fnvHasher struct{}
func (fnvHasher) Sum(b []byte) uint64 { /* ... */ }

// Hot path — called per record in a 50M-row scan:
func bucketize(records [][]byte, h Hasher) []int {
    out := make([]int, len(records))
    for i, r := range records {
        out[i] = int(h.Sum(r) % 1024)   // interface dispatch per record
    }
    return out
}

func BenchmarkConcrete(b *testing.B) { for i := 0; i < b.N; i++ { fnvHasher{}.Sum(data) } }
func BenchmarkIface(b *testing.B)    { var h Hasher = fnvHasher{}; for i := 0; i < b.N; i++ { h.Sum(data) } }

// Production calls the concrete version; tests call bucketizeWith(h).
func bucketize(records [][]byte) []int       { return bucketizeWith(records, fnvHasher{}) }
func bucketizeWith(records [][]byte, h Hasher) []int { /* loop */ }

Scenario 2 — Spring reflection startup vs compile-time DI (Java)¶

Your service uses Spring with classpath scanning. Each test that boots @SpringBootTest takes ~6 s before the first assertion; a 300-test integration suite spends most of its wall time in container startup.

@SpringBootTest                      // boots the full ApplicationContext
class OrderServiceTest {
    @Autowired OrderService service;  // wired by reflection at runtime
    @Test void placesOrder() { /* ... */ }
}

class OrderServiceTest {
    OrderService service = new OrderService(new InMemoryOrders(), new FakeClock());
    @Test void placesOrder() { /* runs in < 1 ms, no context */ }
}

Scenario 3 — Pure functional core tests in microseconds (Python)¶

A pricing rule was tangled with the database read and the HTTP response. Tests required a live DB. You extract a pure function.

# Before: untestable without a DB and a request object.
def handle_quote(request, db):
    customer = db.fetch_customer(request.customer_id)
    discount = 0.0
    if customer.tier == "gold": discount = 0.15
    elif customer.tier == "silver": discount = 0.07
    if request.qty > 100: discount += 0.05
    db.log_quote(...)
    return Response(price=request.unit * request.qty * (1 - discount))

# After: pure core, no I/O.
def quote_price(unit: float, qty: int, tier: str) -> float:
    discount = {"gold": 0.15, "silver": 0.07}.get(tier, 0.0)
    if qty > 100: discount += 0.05
    return unit * qty * (1 - discount)

def test_gold_bulk():
    assert quote_price(10.0, 200, "gold") == 10.0 * 200 * 0.80

Scenario 4 — In-memory fake vs Testcontainers: 8 min → 40 s (Go)¶

Every repository test spins a real Postgres via Testcontainers. The suite takes 8 minutes; developers stop running it locally and CI is the only place it runs.

func TestOrderRepo(t *testing.T) {
    ctx := context.Background()
    pg, _ := postgres.RunContainer(ctx)   // ~2-4s to pull/boot + migrate
    defer pg.Terminate(ctx)
    repo := NewOrderRepo(connect(pg))
    // ... assertions
}

type OrderStore interface {
    Save(ctx context.Context, o Order) error
    ByID(ctx context.Context, id string) (Order, error)
}

// Production: PostgresStore (real SQL).
// Tests of *business logic*: an in-memory fake.
type memStore struct{ m map[string]Order }
func (s *memStore) Save(_ context.Context, o Order) error { s.m[o.ID] = o; return nil }
func (s *memStore) ByID(_ context.Context, id string) (Order, error) { return s.m[id], nil }

Scenario 5 — The Humble Object keeps the slow boundary out of the fast suite (Java)¶

A scheduled job mixes Quartz triggering, JDBC, and the reconciliation algorithm in one class. The only way to test the algorithm is to fire the real trigger against a real DB.

class ReconciliationJob implements Job {
    @Override public void execute(JobExecutionContext ctx) {
        List<Txn> bank = jdbc.query("SELECT ... ");      // I/O
        List<Txn> ledger = jdbc.query("SELECT ... ");    // I/O
        // ... 200 lines of matching logic, the part with all the bugs ...
        jdbc.update("INSERT INTO breaks ...");           // I/O
    }
}

// Humble: thin, almost no logic, not unit-tested (covered by 1-2 integration tests).
class ReconciliationJob implements Job {
    @Override public void execute(JobExecutionContext ctx) {
        var bank = repo.loadBank();
        var ledger = repo.loadLedger();
        var breaks = new Reconciler().match(bank, ledger);   // pure
        repo.saveBreaks(breaks);
    }
}

// Testable: pure, no framework, no I/O.
class Reconciler {
    List<Break> match(List<Txn> bank, List<Txn> ledger) { /* 200 lines, all branches */ }
}

Scenario 6 — A seam adds an allocation in a hot path (Go)¶

You inject a logger interface for testability. Profiling a packet-processing loop shows the injected call is allocating — interface{} boxing on every log argument, in a path that runs per packet.

type Logger interface { Debugf(format string, args ...any) }

func (p *Processor) handle(pkt Packet, log Logger) {
    log.Debugf("recv seq=%d len=%d", pkt.Seq, pkt.Len) // args... boxes ints to interface{} every call
    // ... actual work
}

type Logger interface {
    Enabled(Level) bool
    Debugf(format string, args ...any)
}

func (p *Processor) handle(pkt Packet, log Logger) {
    if log.Enabled(Debug) {                         // cheap bool check, no boxing
        log.Debugf("recv seq=%d len=%d", pkt.Seq, pkt.Len)
    }
    // ... actual work
}

Scenario 7 — Over-mocking costs nothing at runtime but rots the suite (Python)¶

A test mocks every collaborator and asserts on the exact sequence of calls. It passes, runs in 1 ms, and costs nothing at runtime — yet it is a performance problem for the team.

def test_checkout():
    cart = Mock(); pricing = Mock(); tax = Mock(); inv = Mock(); pay = Mock()
    pricing.subtotal.return_value = 100
    tax.compute.return_value = 8
    svc = Checkout(cart, pricing, tax, inv, pay)
    svc.run("order-1")
    pricing.subtotal.assert_called_once_with(cart)
    tax.compute.assert_called_once_with(100)
    inv.reserve.assert_called_once()      # asserts internal call order/shape
    pay.charge.assert_called_once_with(108)

def test_checkout_charges_total_with_tax():
    inv = InMemoryInventory(stock={"sku-1": 5})
    pay = FakeGateway()                          # the one true external boundary
    svc = Checkout(RealCart(["sku-1"]), RealPricing(), RealTax(rate=0.08), inv, pay)
    svc.run("order-1")
    assert pay.last_charge == 108               # asserts the *result*, not the call graph
    assert inv.stock["sku-1"] == 4

Scenario 8 — Fake clock removes sleep-based flakiness and wall-clock waste (Go)¶

A cache-expiry test calls the real clock and time.Sleeps past the TTL. It is flaky under load and wastes real seconds.

func TestExpiry(t *testing.T) {
    c := NewCache(50 * time.Millisecond)   // TTL
    c.Set("k", "v")
    time.Sleep(60 * time.Millisecond)      // wall-clock wait
    _, ok := c.Get("k")
    if ok { t.Fatal("should have expired") }
}

type Clock interface{ Now() time.Time }

type Cache struct{ ttl time.Duration; clk Clock; /* ... */ }

func NewCache(ttl time.Duration, clk Clock) *Cache { return &Cache{ttl: ttl, clk: clk} }

func TestExpiry(t *testing.T) {
    clk := &FakeClock{t: time.Unix(0, 0)}
    c := NewCache(50*time.Millisecond, clk)
    c.Set("k", "v")
    clk.Advance(60 * time.Millisecond)   // instant, deterministic
    if _, ok := c.Get("k"); ok { t.Fatal("should have expired") }
}

Scenario 9 — interface{} / dynamic dispatch defeats JIT monomorphism (Java)¶

A reviewer claims your testability interface will prevent the JIT from inlining and tank a hot method. You need to know when that is actually true.

interface PriceRule { long apply(long cents); }

// Hot accounting loop over 100M line items:
long total = 0;
for (LineItem li : items) {
    total += rule.apply(li.cents());   // virtual/interface call
}

if (rule instanceof FlatRule fr) {        // pattern match to concrete
    for (LineItem li : items) total += fr.applyFlat(li.cents());  // monomorphic, inlined
} else {
    for (LineItem li : items) total += rule.apply(li.cents());
}

Scenario 10 — God constructor does I/O, so every test pays for it (Python)¶

ReportService.__init__ opens a DB connection, reads a config file, and warms a cache. Every test that needs a ReportService — even ones testing pure formatting — pays for all of it.

class ReportService:
    def __init__(self):
        self.db = psycopg2.connect(DSN)          # network on construction
        self.cfg = yaml.safe_load(open("/etc/report.yaml"))
        self.cache = self._warm_cache()           # more queries
    def format_row(self, row): ...                # pure, but you can't reach it cheaply

class ReportService:
    def __init__(self, db, cfg, cache):     # plain assignment, no I/O
        self.db, self.cfg, self.cache = db, cfg, cache
    def format_row(self, row): ...

    @classmethod
    def bootstrap(cls):                     # the I/O lives in a factory, used by main()
        db = psycopg2.connect(DSN)
        cfg = yaml.safe_load(open("/etc/report.yaml"))
        return cls(db, cfg, warm_cache(db))

def test_format_row():
    svc = ReportService(db=None, cfg={"locale": "en"}, cache={})  # no I/O
    assert svc.format_row({"amt": 1200}) == "$12.00"             # microseconds

Scenario 11 — Function injection vs struct-of-interfaces in a tight path (Go)¶

To make a routine testable you debate two seam styles: pass a Notifier interface, or pass a func(Event) callback. Someone worries the closure allocates.

// Style A: interface
type Notifier interface{ Notify(Event) }
func process(events []Event, n Notifier) { for _, e := range events { n.Notify(e) } }

// Style B: function value
func process(events []Event, notify func(Event)) { for _, e := range events { notify(e) } }

Scenario 12 — Test parallelism unlocked by removing global state (Java)¶

The suite runs serially and takes 9 minutes. The reason tests can't run in parallel is a global singleton they each mutate — a testability defect that also caps throughput on a 16-core CI box.

class CurrentTenant {                       // global mutable state
    private static String tenant;
    static void set(String t) { tenant = t; }
    static String get() { return tenant; }
}
// Tests each call CurrentTenant.set(...) and read it back — they leak into each other.

class OrderService {
    private final TenantContext tenant;
    OrderService(TenantContext tenant) { this.tenant = tenant; }   // injected, per-instance
}

// JUnit 5
@Execution(ExecutionMode.CONCURRENT)
class OrderServiceTest { /* each test isolated */ }

Scenario 13 — unittest.mock import & patch overhead at collection time (Python)¶

A 3,000-test pytest suite feels sluggish to start even before any test runs. Profiling collection shows heavy @patch usage and broad imports inflating startup.

from unittest.mock import patch
@patch("app.services.payments.stripe")     # patches at decoration/collection
@patch("app.services.email.smtplib")
@patch("app.services.storage.boto3")
def test_thing(mock_boto, mock_smtp, mock_stripe): ...

def test_thing():
    svc = OrderService(payments=FakeGateway(), email=FakeMailer(), storage=FakeStore())
    # no patching, no boto3 import, no SDK import tree

Rules of Thumb¶

• Measure before de-abstracting. An interface call is ~1–2 ns (Go itab), inlined-to-free at monomorphic JIT sites (HotSpot), and the baseline in Python. Never delete a seam on the assumption it is slow — profile and find it is not.
• Testable design is nearly free at runtime. Constructor injection, ports, pure cores, and humble objects move where code runs, not how much. The JIT inlines the extra method boundaries; escape analysis erases short-lived seams.
• The performance win runs toward the test suite. Pure cores test in microseconds vs seconds for I/O-backed tests; in-memory fakes turn an 8-minute container suite into ~40 s; fake clocks reclaim wall-clock waste and kill sleep flakiness.
• DI cost is startup, not throughput — and it lands on the test suite hardest. Reflection-based wiring (Spring) costs seconds per booted context; share the context, slice it, prefer plain new for unit tests, and reach for compile-time DI (Dagger, Go wire) when boot time matters.
• Optimize the rare measured hot-path seam only — and keep it. When a seam truly costs in a profiled hot path, add a concrete fast path beside the injectable one (Scenario 1/6), gate expensive work behind a cheap predicate, or hoist dispatch out of the loop. Don't delete the seam.
• Watch variadic/boxing, not dispatch. In hot paths the allocation from args ...any / interface{} boxing dwarfs the dispatch — guard it with a level/predicate check.
• Over-mocking has zero runtime cost and a steep maintenance cost. Call-sequence mocks rot the suite by amplifying every refactor into test surgery; mock roles at real boundaries, assert state and return values.
• Fake the clock, randomness, and UUIDs. Determinism removes flakiness and wall-clock sleeps; the injected clock is no slower than time.Now() in production.
• No I/O in constructors. A god constructor makes every test pay for network/disk it may not need; inject collaborators, push side effects into a factory.
• Removing global mutable state buys isolation and parallelism. The same property that isolates tests lets the runner use every core — often a 9 min → 45 s suite win on its own.

Related Topics¶

• find-bug.md — testability defects to spot in code under review (hidden deps, god constructors, untestable boundaries).
• professional.md — the professional discipline of designing for testability up front.
• Chapter README — the positive rules: injected abstractions, seams, pure cores, the humble object.
• Unit Tests — writing the fast, isolated tests this design makes possible.
• Refactoring — extracting pure cores and introducing seams are refactorings; property-based testing rides on a fast pure core.