The Merits of Mocking

The more your tests resemble the way your software is used, the more
confidence they can give you. 
— me

One of the biggest challenges people face with testing is knowing what to test.
There are lots of reasons for that, but one big, flashing-lights reason is
mocking. Many people don’t know when to add a mock version of code or have their
test run the actual code directly. These are challenges I’ll help you work
through in the JavaScript Mocking Fundamentals module of my Testing JavaScript
course.

Mocking lets you fake it so you can make it. If you couldn’t have a fake
version of certain modules or services, testing the checkout process of an app
would cost you a lot of money in credit card fees. Talk about paying a high
price for confidence! 🤑 So instead, we make a fake version of that credit card
charging service to avoid paying the fees.

But mocking comes with a cost of its own.

Mocking severs the real-world connection between what you’re testing and what
you’re mocking. Even if we have confidence that our code works with our fake
version of the credit card service, we can’t have 100% confidence that our code
will work in production with the real version of the credit card service.

When you mock something, you’re making a trade-off. You’re trading
confidence for something else. For me, that something else is usually
practicality — meaning I wouldn’t be able to test this thing at all, or it may
be pretty difficult/messy, without mocking. (Like in our credit card example.)

In my UI unit and integration tests, I have a rule. I never make actual
network calls; instead, I’ll mock the server response by mocking the module
responsible for making the network calls. I’ll also mock animation libraries to
avoid waiting for animations before elements are removed from the page. Other
than that, most of my UI tests are using the real production code. For E2E
tests, I avoid mocking anything (with the exception of the backend hitting fake
or test services and not actual credit card services, for example).

Saving a few milliseconds per test? That’s not a good reason to mock. People
like shallow rendering — component mocking to the max — because it’s faster.
That’s true, but we’re talking milliseconds faster. If it takes a long time to
render your entire component tree, sounds to me like you have a real performance
bug in your software that needs to be addressed. I realize that time adds up
(50ms per test * 1000 tests = 50 seconds). But the less you mock, the fewer
tests you need, and trading confidence for a minute or two faster test suite is
a bad trade. 😵

There’s a time and a place for mocking. And when you need to mock, Jest
makes it easy with some really sweet mocking utilities. In
testingjavascript.com I’ll show you how to
implement some of Jest’s mocking capabilities in raw node so you can get an idea
of what’s going on. It’s brilliant. Here’s an example of simulating Jest’s
inline mock functionality in pure node:

function fn(impl = () => {}) {
  const mockFn = (...args) => {
    mockFn.mock.calls.push(args)
    return impl(...args)
  }
  mockFn.mock = {calls: []}
  return mockFn
}

const utilsPath = require.resolve('~/utils')
require.cache[utilsPath] = {
  id: utilsPath,
  filename: utilsPath,
  loaded: true,
  exports: {
    getWinner: fn((p1, p2) => p1),
  },
}

Now, any code that requires that utils module will get the mock function version
of that module.

It’s not quite as capable as Jest’s inline mocking abilities, but we’ll cover
that in more hands-on detail in the JavaScript Mocking Fundamentals module of
the course!

See you there.