The Code Review Inquisition: Where Are The Tests?

Level 1: The Missing Homework

Imagine you’re in class and the teacher asks you for your homework. You were supposed to check your work (like testing your code), but you didn’t do it. The teacher first asks in a normal voice, “Where is your homework?” and you quietly mumble, “I didn’t do it.” Now the teacher cups a hand to her ear and says, “Louder!” because she wants the whole class to hear. So you end up shouting, “I DIDN’T DO MY HOMEWORK!” in front of everyone, turning red in the face. It’s embarrassing and a little funny because of how over-the-top it is.

In this meme, the developer is like that student – they wrote some code but skipped the “homework” of writing tests to check the code. The friendly cartoon girl (Dora) is like the teacher or a helpful classmate asking about the missing work. When the developer admits softly that they have no tests, she makes them say it louder. The developer ends up yelling in frustration that they have absolutely no tests for their code. It’s a silly, exaggerated way to show the lesson: skipping important steps (like testing your work) can lead to awkward, painful moments later. Just like doing your homework saves you from trouble at school, writing your tests saves you from trouble in a code review. The whole thing is funny because we’ve all felt that mix of shame and frustration when we get caught not doing what we were supposed to – and sometimes you just want to scream about it!

Level 2: No Tests, No Merge

Let’s break down the scene in simpler terms. We have a pull request (PR) – that’s when a developer finishes a piece of code and asks to merge those changes into the main codebase. Think of it like submitting a group project assignment for review. Now, good software practice says any new code should come with tests. A test (specifically a unit test in this context) is a small piece of code that checks if the new code works correctly. For example, if the code adds two numbers, a test would call that code with 2 and 2 and expect to get 4. If the code does something more complex like updating a user profile, a test might simulate that and verify the profile was updated as expected. Tests act as proof and protection: proof that your code does what it’s supposed to, and protection against future changes breaking it (because if someone breaks this functionality later, the test will fail and alert us).

In the meme, Dora the Explorer is depicted as the code reviewer or the automated tool asking “Where are the tests in the pull request?” This is a very common question in code reviews on platforms like GitHub or GitLab. Reviewers often leave comments like “Please add tests for this change” if none are present. Why? Because without tests, there’s no guarantee the code actually works or won’t break something else. The developer, represented by Pepe the Frog, replies sadly “I have no tests.” That’s the developer admitting they didn’t write any tests for their code – maybe they were in a hurry, or didn’t know how to write a test for this case, or hoped it wasn’t necessary.

Dora then says “Louder!” which is a funny way of essentially saying “Tell the whole class what you just told me.” It’s like a teacher catching a student who didn’t do their homework and saying “I didn’t hear that, could you repeat it for everyone?” In Dora’s children’s show, she often asks the audience to repeat answers louder if she didn’t hear, so this meme uses that device humorously in a developer scenario. The final panel shows Pepe turning red and screaming “I HAVE NO WORKING TESTS IN THE PULL REQUEST!!!!” in all caps. This exaggeration is the meme’s punchline. It’s portraying the developer’s embarrassment and frustration at having to admit loudly that they skipped this important step. The term “working tests” hints that even if there are some tests, maybe they’re broken or incomplete – but here it’s basically zero tests present.

From a junior developer’s point of view, the lesson is clear: always include tests with your code changes. Teams expect it, and many automated CI (Continuous Integration) systems will even run your tests every time you push a PR. If any test fails, or if coverage is too low, the system might mark your PR with a red X and won’t allow it to be merged until things are fixed. Some projects set a rule like “no tests, no merge,” meaning they literally won’t merge your code until you add sufficient tests. This is often enforced by something called a CI gate or quality gate. For instance, if you add 100 lines of code and your tests cover 0 of those lines, a coverage tool might report that as a drop in overall coverage percentage, and the CI will fail the build. It’s like an automatic reviewer that checks your homework and says “you missed a spot.” In our meme, Dora is that voice of the CI or the diligent reviewer who just won’t let the missing tests slide.

It’s also worth noting the use of characters: Dora the Explorer is typically a cheerful, educational cartoon character. Here she’s used ironically as the enforcer of strict coding practices (imagine Dora cheerfully demanding unit tests – that contrast is funny by itself). Pepe the Frog is an internet meme character often used to represent a range of emotions; here we see a sad Pepe and then an enraged Pepe. That represents the developer’s emotional journey: from ashamed/defeated when quietly admitting “no tests,” to furious/frustrated when basically being forced to admit it loudly (maybe to a whole team or just feeling the intensity of the moment). The red, blurred image of Pepe is a meme way to show intense anger or stress, often called a “rage meme.” And the text “REEEEE~” in the post is internet slang for an angry, high-pitched scream (it’s something memers use to mimic the sound of a frustrated frog or nerd rage).

All these elements put together resonate with developers because code reviews can be stressful, especially when you realize you forgot something important like tests. It’s a mix of humor and a gentle reminder: next time, write your tests upfront to avoid this kind of loud call-out. After all, it’s much nicer to have your tests ready so the reviewer says, “Good job on the tests,” rather than having a Dora shout you into a confession.

Level 3: Shout-Driven Development

In a modern code review culture, a pull request without tests is like a minefield waiting to blow up in production. Experienced developers have all seen that pull request where the author blithely submits new code with no unit tests, hoping it slips under the radar. But in well-run projects, there's always a Dora-the-Reviewer figuratively standing over your shoulder asking, "Где тесты в пулл реквесте?" – “Where are the tests in the pull request?” This meme exaggerates that scenario using Dora the Explorer and Pepe the Frog to personify the interaction. Dora acts as the relentless code reviewer or a CI pipeline gatekeeper, while Pepe represents the hapless developer caught without tests.

On the technical side, failing to include automated tests in a PR breaks continuous integration rules and team conventions. Many projects have a CI gate that runs all tests on every PR. If you didn’t write tests, that gate might literally fail or at least a reviewer will demand them before merging. Some teams use tools like code coverage reports (e.g. Coveralls or SonarQube) that will flag or even reject a PR if coverage drops below a threshold. So when Pepe quietly says, “У меня нет тестов” (“I have no tests”), it’s the admission that this code has zero automated verification. The reviewer (Dora) shouting “Громче!” (“Louder!”) is a figurative way of cranking up the pressure – essentially saying, "I can't hear your excuse – say it again so everyone knows!" This is a humorous take on the “louder for those in the back” meme trope, combined with the developer’s worst nightmare: having to openly confess “I have no working tests in this PR!” at full volume.

The humor here is laced with dark truth. Not writing tests is a cardinal sin in many engineering teams focused on code quality. It’s funny because it’s painfully relatable – almost every developer, especially juniors or those racing against deadlines, has at some point submitted code without tests and then faced the embarrassment of a reviewer pointing it out. The meme’s final panel – a rage-blurred Pepe screaming in all-caps – perfectly captures that mix of frustration and humiliation. It’s the developer’s internal scream made external: the frustrated “REEEEE” of realizing they’re about to spend the afternoon writing those missing tests or risk their PR being rejected. The all-caps shouting isn’t just for laughs; it mirrors how code reviews can sometimes feel like being yelled at when you mess up, even if everyone is polite in text.

From a senior perspective, this scenario highlights the underlying industry best practice: every new feature or bugfix in a PR should come with tests to prove it works and won’t break existing behavior. The meme implicitly references how CI/CD pipelines often enforce this (like a friendly-but-firm Dora querying every PR). If tests are missing, the pipeline or the reviewer essentially says “I’m not merging this until you prove it works.” We also get a glimpse of the emotional tech debt here: skipping tests might save time now but you will pay for it later, either by an angry reviewer, a failing pipeline, or worst of all, a production bug at 3 AM. Seasoned devs chuckle at this meme because they’ve been on both sides: the battle-scarred reviewer insisting on tests after being burned by untested code before, and the tired developer whispering “I didn’t write any” thinking maybe, just maybe, it’ll slide through. Spoiler: it never slides through. Quality gates exist for a reason — to save everyone from that one-line change taking down the app because nobody wrote a test. In summary, the meme’s comedy stems from a very real tension in software development: the classic showdown between speedy coding and disciplined testing, dramatized here as a cartoonish shouting match.