Every JavaScript developer has written jest.mock() at least once, thinking they were creating a mock. They weren't. Maybe that's the real jest in Jest: the function name that turned the testing world into a linguistic punchline. We thought we were mocking our code. Turns out, it was mocking us.
In classic testing vocabulary, a mock is a test double that carries its own expectations. The assertion lives inside the test double. A spy observes; a stub returns canned data; a mock enforces a contract by failing if the expected interaction doesn't occur. But in JavaScript, jest.mock() redefined the term to mean something else entirely: patching a module's exports. I'm not sure who gave them that right, but that's not mocking, it's f*ing replacing. Somewhere between Java, Python, and Node, the word mock completely lost its meaning.
Some people will tell you Javascript developers (and I'm included here) should not be trusted with anything serious. Who can blame them?
Despite the name, jest.mock() doesn't create a mock. It intercepts imports, rewires bindings, and substitutes modules before anything runs. The result is clever, powerful, and misleading alright. But that's not all. The whole thing is a trap. It lures you into a false sense of security, making you think you're isolating your tests when you're actually just cutting them off from reality.
If you need to intercept a module and replace it with something else, jest.mock() is your tool. (But why in hell would you want to do that?) Testing is all about creating controlled environments to verify behaviour. When you replace a module wholesale, you risk losing the context that gives your tests meaning. You test implementation. You give knowledge to the mock and take it away from the test. The test becomes an empty shell, an hollow echo of the real behaviour. And worse still: you might not even notice. Your tests pass, but they don't even prove the thing you think they do.
You probably (hopefully) can't hear it from there, but I'm literally shouting here. Don't use jest.mock() unless you have a very good reason. Prefer dependency injection, factory functions, or other patterns that let you control collaborators without wholesale replacement. Use spies and stubs to observe and simulate behaviour, not to rewrite it. Keep your tests close to reality, not to your imagination of it.
Other ecosystems like Python are more careful about naming, but still use similarly dangerous concepts. Python calls it patch(). That's probably where it started. Everywhere else, mock means simulate a collaborator with built‑in expectations. Only in JavaScript did it become a kind of global patching spell. The shittiest part is that Javascript is so ubiquitous, this misnomer has spread far and wide. No other dev community has so thoroughly confused the concept of mocking.
Language drifts, and naming mistakes become history. We live surrounded by misnomers: Bluetooth has no blue and no teeth, hamburgers contain no ham, artificial intelligence is not particularly intelligent, and your phone camera is more camera than phone, nowadays. jest.mock() belongs in that same pantheon: familiar, powerful, and fundamentally misleading. There's a quiet poetry in that: a function named mock that deceives you about what it does.
Over time, this small distortion reshaped how developers think about testing. Tutorials teach people to "mock a module," newcomers talk about "mocking functions," and the original meaning quietly dissolves. The line between mocking and being mocked has thinned. Jest blurred it.
We don't need to rename it, really. It is too late for that. But we do need to remember what it used to mean. Mocking has a history in our industry, and it's important to honor that. Language shapes how we test and how we think. Precision in testing begins with precision in words. And maybe the next time you type jest.mock(), you'll hear the echo: here is the function that mocked us all.
Top comments (0)