When running unit tests, you don’t want to actually make network requests or charge real credit cards. That could… get expensive… and also very, very slow. So instead of running your code exactly as it would run in production, you can modify how some of your JavaScript modules and functions work during tests to avoid test unreliability (flakiness) and improve the speed of your tests. This kind of modification can come in the form of stubs, mocks, or generally: “test doubles.”

There are some great libraries and abstractions for mocking your JavaScript modules during tests. [The Jest testing framework](https://facebook.github.io/jest) has great mocking capabilities built-in for [functions](https://facebook.github.io/jest/docs/en/mock-functions.html) as well as entire [modules](https://facebook.github.io/jest/docs/en/manual-mocks.html). To really understand how things are working though, let’s implement some of these features ourselves.

Intro to JavaScript Mocking Fundamentals 

Mocking allows our tests to be deterministic and ensure that we will get the expected result every time.

The most naïve approach to mocking in JavaScript is to override an object’s properties in the test. This is pretty simple and straightforward, but also fairly limited. In this lesson, we’ll monkey patch our `getWinner` function to always return the same winner every time the function is called. After the test is run, we’ll clean up the mock and assign the original function implementation back to `getWinner`.

Override Object Properties to Mock with Monkey-patching in JavaScript

Often when writing JavaScript tests and mocking dependencies, you’ll want to verify that the function was called correctly. That requires keeping track of how often the function was called and what arguments it was called with. That way we can make assertions on how many times it was called and ensure it was called with the right arguments.

Ensure Functions are Called Correctly with JavaScript Mocks

With our current usage of the mock function, we have to manually keep track of the original implementation so we can clean up after ourselves to keep our tests idempotent. Let’s see how jest.spyOn can help us avoid the bookkeeping and simplify our situation.

Restore the Original Implementation of a Mocked JavaScript Function with jest.spyOn

So far we’re still basically monkey-patching the utils module which is fine, but could lead to problems in the future, especially if we want to mock a ESModule export which doesn’t allow this kind of monkey-patching on exports. Instead, let’s mock the entire module so when our test subject requires the file they get our mocked version instead.

Mock a JavaScript module in a test

Often you’ll want to mock the same file throughout all the tests in your codebase. So let’s make a shared mock file in Jest's `__mocks__` directory which Jest can load for us automatically.

JavaScript Mocking Fundamentals

Instructor

Course Content