The Pull Request Has Tests, None Working

Level 1: The Unchecked Homework

It is like bringing homework to a teacher and saying the answer sheet exists, but none of its answers can be checked. The teacher first asks where the checking work is; after some pressure, the student admits that the pages are there but do not actually prove anything. The scream is funny because saying the embarrassing problem louder does not fix it—it only makes everyone understand how much work is still waiting.

Level 2: What Green Means

A pull request asks teammates to review a set of code changes before those changes are merged into a shared branch. Reviewers inspect readability and design, but they also need evidence that the change behaves correctly. Automated tests provide repeatable examples: given some input and setup, the program should produce a specific result.

A unit test usually checks a small piece of code in isolation. An integration test checks whether multiple pieces cooperate. Continuous integration, or CI, runs such checks automatically when code is pushed. A healthy workflow looks roughly like this:

1. The author changes behavior and adds or updates relevant tests.
2. The same test command works on the author’s machine and in CI.
3. CI reports a clear pass or a useful failure.
4. Reviewers inspect both the production code and what the tests actually prove.

The distinction in the meme matters because a broken test suite gives neither safety nor speed. A reviewer cannot tell whether a failure comes from the new feature, old infrastructure, or the test itself. Every ambiguous red result becomes manual investigation. For a junior developer, the practical lesson is to run the repository’s documented test command before requesting review, read the CI output, and fix or clearly explain failures. “There are test files” answers a file-count question; “the tests pass and cover the changed behavior” answers the engineering question.

Dora’s simple wording also reflects a normal review boundary. The reviewer is not demanding mathematical proof that the software has no defects. Tests cannot establish that. She is asking the author to share the verification work rather than handing over code plus a mystery. Pepe’s anguished face is funny because nearly every developer eventually discovers that writing the feature was the short part; making its environment, fixtures, mocks, and edge cases behave is where the adventure map stops helping.

Level 3: Red Is Not Coverage

“Where are the tests in the pull request?”

“I DON’T HAVE ANY WORKING TESTS IN THE PULL REQUEST!!!!”

The final confession adds the word “working,” and that qualifier contains the entire code-review horror story. The first answer suggests that no tests were written. The louder answer implies something arguably worse: test-shaped material may be present, but it cannot give the reviewer a reliable verdict. A file under tests/ is not evidence by directory placement. It becomes evidence only when it runs in the expected environment, exercises the claimed behavior, fails for the right reason when that behavior is broken, and passes when the implementation is correct.

That makes the four-panel escalation technically precise even while its logic is delightfully slippery. Dora begins calm and folded-armed, then raises both hands and demands “Louder!” Pepe moves from sad resignation to a red, motion-blurred scream. The visual intensity tracks the widening admission: this is no longer a small omission that a reviewer can request in one comment; it may be a broken verification path whose repair exposes problems in the implementation, fixtures, dependencies, or continuous-integration setup.

“Not working” can cover several distinct failures:

• The tests do not compile or import because interfaces changed.
• They pass locally but fail in continuous integration because they depend on machine-specific state.
• They are flaky, producing different results from the same code because of timing, randomness, shared state, or external services.
• They assert implementation details so tightly that a harmless refactor breaks them.
• They are skipped, disabled, or never discovered by the test runner.
• They fail correctly because the feature is broken, but the author submits the pull request anyway and transfers diagnosis to the reviewer.

These cases produce different engineering work, yet all destroy the same thing: trust in the signal. A green pipeline should mean the agreed automated checks passed. A red pipeline should identify an actionable regression. If red is the permanent background color, teams learn to merge around it, rerun jobs until flakes disappear, or memorize which failures are “normal.” That is alert fatigue applied to quality assurance. Soon the repository has plenty of tests and very little tested confidence—the software equivalent of installing smoke alarms and removing their batteries because they are noisy.

The meme also captures a code-review incentive problem. Feature work is visible and deadline-friendly; repairing test infrastructure is often diffuse, unplanned, and owned by everyone in theory. Under pressure, an author may treat tests as the reviewer’s optional request rather than part of the change. Reviewers then face a bad choice: block delivery and appear bureaucratic, or approve code whose risk they cannot cheaply evaluate. Repeating the question more loudly cannot create engineering time, but it can force the hidden trade-off into the open.

Good pull-request policy therefore focuses on outcomes, not ritual. A change should include appropriate automated checks, clear reproduction steps where automation is impractical, and a pipeline that newcomers can run without archaeological fieldwork. Test coverage can show which lines executed, but it cannot prove that assertions are meaningful or that important behaviors were chosen. One excellent regression test is more useful than a hundred assertions that merely confirm the mocks returned what the mocks were told to return. The senior move is not “always add more tests”; it is “make the risk and the evidence legible.”