Test Coverage Review

Phase 2 — Behavioral Mapping

Map each meaningful behavioral change in the code to its corresponding test coverage. This is the core analytical step that separates a useful review from a naive "this function has no test file" checklist.

Practical approach:

1. Start from the diff (or specified files). For each changed function, method, or code path, identify the behavior it implements — what it accepts, what it returns, what side effects it produces, and what errors it can throw.
2. Search the test files (found in Phase 1) for tests that exercise each behavior. Look for the function name, the module import, or the API endpoint in test files. Check both direct unit tests and indirect coverage through integration or higher-level tests.
3. For each behavior, classify it: directly tested (a test explicitly calls it and asserts on the result), indirectly covered (exercised through a higher-level test that verifies the end-to-end outcome), or untested (no test exercises this code path with any assertion).
4. Compare against analogous tests. Before concluding a behavior is untested, check how similar functionality is tested elsewhere in the codebase. If the project tests comparable code paths a certain way, the changed code should follow the same pattern — and if it already does, it's not a gap.
5. Pay special attention to error paths, boundary conditions, and validation logic — these are where untested code most commonly causes production incidents, because they're exercised rarely during development but frequently in production.

This mapping prevents both false positives (flagging something already tested elsewhere) and false negatives (missing a real gap because you didn't trace the full behavior chain).

Phase 3 — Issue Assessment

With the behavioral map established, assess specific gaps and quality issues through the dual scoring system. For every potential finding, assign both a confidence score and a criticality rating before deciding whether to report it.

Focus Areas

Coverage Gap Analysis

Look for behavioral changes that lack corresponding test verification. The question for each gap: "If someone breaks this code six months from now, what will alert them?"

• Untested error handling paths. Code that catches exceptions, handles null returns, or manages failure states but has no test proving the error path works correctly. Error handling code is rarely exercised during normal development — if it's wrong, you'll only discover it during an incident, which is the worst possible time.

• Missing edge case coverage. Boundary conditions like null, empty, zero, negative, and maximum values. Functions that accept a range of inputs but are only tested with the happy-path case. Look for boundary conditions in loops, string operations, array processing, and arithmetic.

• Uncovered business logic branches. Conditional logic that implements important rules — pricing calculations, permission checks, state transitions, feature flags — where only some branches have test coverage. If the else branch is important enough to write, it's important enough to test.

• Missing negative test cases. Validation logic that tests what happens with valid input but not what happens with invalid input. If a function should reject certain inputs, there should be tests proving it actually does. This is especially important for public APIs and user-facing input handling.

• Async behavior and state transitions. Code involving promises, callbacks, event handlers, or state machines where ordering and timing matter. These are disproportionately likely to have subtle bugs that only surface under specific conditions — and are the hardest bugs to reproduce and diagnose after the fact.

• Integration boundaries. Module boundaries, API contracts, and data transformation layers that are only tested in isolation through mocked unit tests. When module A produces output that module B consumes, is there a test verifying the two sides agree on the shape and semantics of the data?

Test Quality Assessment

Existing tests can provide a false sense of security if they're poorly designed. These tests pass today but won't catch tomorrow's bugs:

• Tests coupled to implementation details. Tests that mock internal methods, assert on how many times a private function was called, or break when you rename a local variable. The key question: would this test still pass if the code were refactored to produce the same external behavior through a different internal approach? If not, the test is testing the how rather than the what, and it will hinder refactoring without actually guarding behavior.

• Over-mocking. Tests where so many dependencies are mocked that the test is really just verifying the mock wiring, not actual behavior. The danger: these tests pass even when the real integration is broken. If a test mocks the database, the HTTP client, and the cache, ask what it's actually verifying — if the answer is "that the code calls the mocks in the right order," it's not providing real protection.

• Weak assertions. Tests that assert toBeTruthy() or toBeDefined() when they should assert on a specific value. A test that checks expect(result).toBeTruthy() will pass even if the result changes from the correct user object to the string "error". Assertions should verify the specific thing you care about.

• Test isolation violations. Tests that depend on execution order, share mutable state across test cases, or rely on side effects from previous tests. These create intermittent failures that erode confidence in the test suite. Each test should be independently runnable and produce the same result regardless of what tests ran before it.

• Complex test setup that obscures intent. When the arrangement code is longer than the actual assertion, the test becomes hard to understand and maintain. If you can't tell what a test verifies within a few seconds of reading it, the test has a clarity problem that will make it harder to update when requirements change.

• Non-descriptive test names. Names like test1, it("works"), or should handle case don't describe the behavior being verified. Following DAMP principles (Descriptive and Meaningful Phrases), test names should read as documentation of the system's contracts: it("returns a validation error when email is empty") tells you exactly what behavior is being protected. Note: poor naming alone is a style issue (criticality 3-4) unless it makes it impossible to tell whether critical behavior is actually being tested — in that case the naming problem is masking a potential coverage gap, which raises the criticality.

Test Design Issues

Beyond individual test quality, look at structural patterns across the test