Reading a Codebase's Test Suite Before Reading Its Code

# Reading a Codebase's Test Suite Before Reading Its Code The fastest read I've found on an unfamiliar codebase's real quality isn't the code. It's the test suite, read before the code it tests — because a test suite tells you what the team believed was worth protecting, and the gap between that and what should have been protected is often the whole due-diligence finding in one pass. ## A test suite is a confession of priorities Code shows you what was built. Tests show you what the people who built it were afraid of breaking. Those are different signals, and the second one is harder to fake convincingly, because writing a thorough test for something you don't actually understand well is much harder than writing code that happens to work for the cases you tried. In one review, the billing module had extensive tests — dozens of cases covering discount stacking, proration, currency rounding. The auth module, which gated access to that same billing data, had four tests, all happy-path. That asymmetry told me more in five minutes than an hour of reading either module's code would have: the team had, correctly, treated billing correctness as something that would generate support tickets and revenue disputes if wrong, and had, less defensibly, treated auth as something that either obviously worked or obviously didn't. Auth bugs are rarely obvious. They're usually a permission check that's correct for the case everyone tested and wrong for a case nobody thought to write down. ## Coverage percentage is close to useless; coverage shape is not A single coverage number — eighty percent, ninety percent — tells you almost nothing about where the risk sits, because it averages across a codebase in a way that hides exactly the concentration that matters. What matters is which eighty percent. A codebase with ninety percent coverage that's evenly distributed across low-risk utility functions and completely absent from its payment-processing webhook handler is in worse shape than one with sixty percent coverage concentrated on the code paths that would actually cause an incident if they broke. Getting to that shape means looking at coverage per-module against a rough model of blast radius per-module, not looking at the aggregate. It's slower than reading one number off a dashboard. It's also the only version of the question that's actually answering "where is this codebase fragile," rather than "how much of this codebase has been executed at least once by some test." ## What the absence of a test tells you that its presence can't The most useful finding in this kind of review usually isn't a bad test — it's a missing one, in a place the code's own complexity suggests a test should exist. A gnarly, deeply-nested reconciliation function with no tests around it isn't neutral information. It's a signal that either the function is simpler than it looks and nobody noticed, or it's exactly as fragile as it looks and nobody has verified otherwise, and you don't know which until you go read the function itself. That's the actual value of reading tests first: it doesn't replace reading the code, it tells you where to spend the time once you get there. A codebase's test suite is the fastest available map of what its own authors trusted and didn't trust about their own work — and the parts they didn't trust enough to test are usually the parts worth reading most carefully.