Learn

The test is named after two cases and checks only one of them

29 October 2026 · Code review: find it, then defend it

The interviewer shares a pull request with a one-line fix and a new test. The test is green, its name describes exactly the bug the title mentions, and you are tempted to approve. The name is the thing to distrust: it is a claim about coverage, and the body of the test is the evidence.

The situation

Here is an original example. The pull request title is "Fix: the last partial page was never shown". The list view had 25 orders, 10 per page, and only two pages appeared. The change and the new test:

// before
static int pageCount(int total, int pageSize) {
    return total / pageSize;
}

// after
static int pageCount(int total, int pageSize) {
    return (total + pageSize) / pageSize;
}

@Test
void pageCountHandlesExactAndPartialPages() {
    assertEquals(3, pageCount(25, 10));
}

The test fails on the old code and passes on the new one, so it does test something. The name says it covers two cases: a total that fills its pages exactly, and one that leaves a partial page. The body checks one number, and it is the partial case.

What goes wrong, with the input that shows it

Put the inputs around the boundary in a small table before you form an opinion. With a page size of 10:

• total 21: before 2, after 3, expected 3.
• total 25: before 2, after 3, expected 3.
• total 20: before 2, after 3, expected 2.
• total 0: before 0, after 1, expected 0 or 1, depending on what the screen shows for an empty list.

The fix repaired the partial case and broke the exact one. With 20 orders, the view now offers a third page with nothing on it. The case the test name promised is the case that regressed, and no test fails, because the only exact-multiple check lived in the name.

The correct arithmetic is a ceiling division. The familiar form, (total + pageSize - 1) / pageSize, overflows when total is near Integer.MAX_VALUE. On Java 18 or later, Math.ceilDiv(total, pageSize) gives the right answer for every non-negative total. Mentioning the overflow is a bonus; the empty page is the finding.

Now argue the severity with evidence rather than adjectives:

• Who gets hurt? Anyone whose order count is a multiple of the page size. They click Next and see an empty page. If a nightly export loops over pages, it writes one empty file per run.
• When does it show? Only on exact multiples, so roughly one list in ten with this page size. Easy to miss in a demo.
• Can it be undone? Yes. No data is lost, and the fix is one line.

That makes it a real defect of medium severity: visible, cheap to fix, not dangerous. Say that. Calling it critical costs you as much credibility as missing it.

What to say out loud

"The test fails before the change and passes after it, which is good, but its name says exact and partial pages and it only checks 25. I tried the boundary on both sides. With 20 orders the new code returns 3 pages, so the exact case regressed and users get an empty last page. I would request changes, not block hard: no data is lost. The fix is Math.ceilDiv, and I would split the test into two, one for 20 and one for 21, so each name matches what it asserts. One question for the author: with zero orders, should the screen show page 1 of 1, or no pager at all?"

That answer shows you read the test as evidence, found the input that breaks the claim, sized the harm honestly, and left the one product decision to the person who owns it.

The exercise

1. Open a test file from your own code and pick five test names at random.
2. For each one, write down what the name promises, then read the body and write what it actually asserts.
3. Where the two differ, write the input the name implies but the body never uses.
4. For one of the functions, list the inputs on both sides of its boundary, including zero, and predict each result before you run anything.
5. Say aloud in under thirty seconds: the claim, the missing input, the effect, and how severe it is and why.

Where this fits in Gadfly

Gadfly has four rooms: algorithms, system design, behavioral and code review. The code review room takes a class you wrote yourself, a connected GitHub repository, or a project from its catalog, and reviews it together with the transcript of how the code was produced. It does not execute the code, so a boundary table like the one above is something you build and reason through aloud. Code review is part of a session pack. You code in Java or Python, and the tutor speaks English.