DEV Community: Dave Cooper

Mocking the window object in unit tests

Dave Cooper — Mon, 23 Mar 2020 09:01:04 +0000

Hi there!

Let's talk about how to properly mock that pesky browser window object in a unit testing environment.

Recently, I implemented some functionality that leveraged the browser's performance API to help with measuring an initial page render time.

The code looked something similar to this:

performance.ts

export const measureInitialPageLoad = () => {
  if (
    window.performance
      .getEntries()
      .filter(el => el.name === "MY_APP_INITIAL_PAGE_RENDERED").length === 0
  ) {
    window.performance.measure("MY_APP_INITIAL_PAGE_RENDERED");
  }
};

The code above does the following:

Defines a function called measureInitialPageLoad.
Calls window.performance.getEntries() to get an array of PerformanceEntry objects made by the browser.
Filters the list of PerformanceEntrys to see if any of them are called MY_APP_INITIAL_PAGE_RENDERED.
- We have prepended MY_APP to this PerformanceEntry to help ensure that nothing else is generating a PerformanceEntry called INITIAL_PAGE_RENDERED.
If we haven't measured this before (i.e. if the filter returns an array of length 0), then we call window.performance.measure() to create a named PerformanceEntry.

Pretty straightforward and fairly uninteresting, right?

Well, it starts to get interesting right around the time you need to write some unit tests for this piece of code. We've all been there - writing unit tests for code that leverages the window object but a lot of the time you don't stop and think about what the window object actually is and why it can sometimes feel a bit odd writing unit tests around it.

To unit test this function, we need to reliably manipulate the window.performance object to do two things:

Return a desired array of PerformanceEntry objects when window.performance.getEntries() is called.
Track whether of not window.performance.measure has been called.

One approach might be to try do something like:

Note: tests are written using Jest

performance.spec.ts

import { measureInitialPageLoad } from "./performance";

describe("performance", () => {
  it("Calls measure when we have not already measured the initial page rendering", () => {
    window.performance = {
      getEntries: jest.fn().mockReturnValue([]),
      measure: jest.fn()
    };

    measureInitialPageLoad("INITIAL_PAGE_RENDERED_TEST");
    expect(window.performance.measure).toHaveBeenCalled();
  });
});

This is something I commonly see to try hack around the window object in unit tests and for some things it does work. However, it turns out the window.perfomance object is read only. Uh oh - this won't work!

You'll be left with an error that looks like:

Cannot assign to 'performance' because it is a read-only property.

Not to mention, it's harder to clean up your mocks inbetween tests if you set things directly on the window object like this.

Admittedly, this was the first thing I tried and left me feeling a bit baffled. I searched around for some examples online of other people trying to mock read-only window objects and the closest thing I could come across was something like this:

performance.spec.ts

import { measureInitialPageLoad } from "./performance";

describe("performance", () => {
  it("Calls measure when we have not already measured the initial page rendering", () => {
    delete (window as any).performance;

    const performance = {
      measure: jest.fn(),
      getEntries: jest.fn()
    };

    Object.defineProperty(window, "performance", {
      configurable: true,
      enumerable: true,
      value: performance,
      writable: true
    });

    measureInitialPageLoad("INITIAL_PAGE_RENDERED_TEST");
    expect(window.performance.measure).toHaveBeenCalled();
  });
});

Basically, we delete performance off the window object... but to do that, we have to cast as any because in the Jest testing environment, we're actually referring to the NodeJS window which doesn't have performance defined on it. We then add a writeable performance object to window with our Jest mocks and away we go.

This works... but it's not so great:

It deletes something from the window object.
- That sounds/feels a bit weird, doesn't it?
We have to define a new property on window with a writeable performance object.
- How many times have you had to do something like this before? I'm guessing the answer to this is zero.

Ideally, what we want is a window that behaves normally but allows us to mock objects on it in the same way, no matter if the object was originally read-only or not. For example, the pattern used to mock something on the window.location object is exactly the same as the pattern used to mock something on the window.performance object.

🎉 It turns out we can do that 🎉

To do this, we need to:

Export a copy of the window object from a module.
Use that copy in our code.
Once the two things above have been done, we can then mock the window object properly in our tests.

Let's do it!

First, let's export a copy of the window object.

Unfortunately, neither TypeScript nor Jest allow us to do:

window.ts

export { window };

So we have to create a copy and export that instead:

window.ts

const windowCopy = window;

export { windowCopy as window };

Okay, first step done. Next, let's change our references to window in our code to use the copy we are now exporting:

performance.ts

import { window } from "./window";

export const measureInitialPageLoad = () => {
  if (
    window.performance
      .getEntries()
      .filter(el => el.name === "MY_APP_INITIAL_PAGE_RENDERED").length === 0
  ) {
    window.performance.measure("MY_APP_INITIAL_PAGE_RENDERED");
  }
};

That was easy - adding the import was the only thing we needed to do!

Lastly, let's mock the window object in our test (I've also included the other test that I wrote for this particular function):

performance.spec.ts

import { measureInitialPageLoad } from "./performance";

import { window } from "./window";

jest.mock("./window", () => ({
  window: {
    performance: {
      measure: jest.fn(),
      getEntries: jest.fn()
    }
  }
}));

describe("performance", () => {
  it("Calls measure when we have not already measured the initial page rendering", () => {
    (window.performance.getEntries as jest.Mock).mockReturnValue([]);
    measureInitialPageLoad("INITIAL_PAGE_RENDERED_TEST");
    expect(window.performance.measure).toHaveBeenCalled();
  });

  it("Does not call measure when we already have measured the initial page render", () => {
    (window.performance.getEntries as jest.Mock).mockReturnValue([
      "INITIAL_PAGE_RENDERED_TEST"
    ]);
    measureInitialPageLoad("INITIAL_PAGE_RENDERED_TEST");
    expect(window.performance.measure).not.toHaveBeenCalled();
  });
});

And there we have it - a pattern that can be used to mock anything on the window object, regardless if it is read-only or not. The only thing to remember here is that when you want to mock a return value, you still need to cast the function you're mocking to jest.Mock as TypeScript isn't quite smart enough to work out that we are actually dealing with a mock at compile-time.

Concluding thoughts

Personally, I really like this pattern of working with window in unit tests because it provides a consistent pattern to mock anything we need regardless of what it is we're trying to mock. The window object is a funny one because sometimes it's not always clear how to work with it in a testing environment.

I'd love to hear everyone's thoughts on this and to share how they deal with mocking window in their testing environments!

-Dave

Sanely Testing React Hooks

Dave Cooper — Fri, 17 Jan 2020 09:32:51 +0000

Hi there 👋 Let's talk about how to test React hooks.

Suppose we have a React application (with TypeScript) that uses Redux for state management.

Suppose inside said application you have a hook that does the following:

Dispatch an action which ends up make an API call to get a thing and put it into state.
Returns that thing from state.

It might even look like this:

useThing.ts

import { useSelector, useDispatch } from "react-redux";
import { useEffect } from "react";
import { getThingStart } from "./redux/actions";

const useThing = () => {
  const dispatch = useDispatch();
  useEffect(() => {
    dispatch(getThingStart());
  }, [dispatch]);

  return useSelector(state => state.thing);
};

export { useThing };

We can then use this hook inside a component:

MyComponent.tsx

import React from "react";
import { useThing } from "./useThing";

const MyComponent = () => {
  const { thing } = useThing();

  if (!thing) {
    return <div>Loading...</div>;
  }

  return <div>This is your thing: {thing}</div>;
};

We might even have many components that use this hook.

We probably want to test that this hook behaviour works as expected.

How do we do this? What would good tests for this look like?

The most common way I see custom hooks being tested is by testing a component that uses the custom hook. I'm really not a fan of this as component can have so many things going on inside them that could effect the internal state of a component. This effects the confidence we can have in the test which isn't really what we're aiming for.

Since we can't call hooks outside of components (with some exceptions), I also see people wrapping their hooks with dummy components. I'm not sure if this is better or worse than the previously mentioned strategy, but it still doesn't make me happy. There are also cases of when things don't go according to plan within the component that probably aren't being catered for in a simple dummy component.

Why don't we try treat testing hooks as closely as we can to unit testing a regular JavaScript function? After all, hooks are just functions...

Fortunately, we can write tests for our hooks in this style thanks to react-hook-testing-library. It provides a renderHook function which lets us pass in our hook and execute it. Under the hood, renderHook is using the hook within a dummy component, but the difference here is:

To the test-writer, it appears that we are just executing a function with a callback - not an uncommon thing to do.
The dummy component is very defensively programmed and can handle pretty much any error/exception case gracefully (it's actually somewhat complicated to do)
- I took a look through the source code for this function and I'm really glad it wasn't me that had to write it...

Let's see what tests for this hook might look like (using Jest):

useThing.spec.ts

import { renderHook } from "@testing-library/react-hooks";
import { getThingStart } from "./redux/actions";
import { useThing } from "./useThing";

jest.mock("react-redux", () => ({
  useSelector: jest.fn(),
  useDispatch: jest.fn()
}));

const mockUseSelector = useSelector as jest.Mock;
const mockUseDispatch = useDispatch as jest.Mock;
const mockDispatch = jest.fn();

describe("useThing hook", () => {
  it("calls dispatch and retrieves our thing", () => {
    mockUseDispatch.mockImplementation(() => mockDispatch);
    mockUseSelector.mockImplementation(
      callback => callback({ thing: "this is our thing" }) // This is our mocked state.
    );

    const { result } = renderHook(() => useThing()); // Call our hook.

    expect(result.current).toBe("this is our thing"); // Make sure hook returns our slice of state.
    expect(mockDispatch).toHaveBeenCalledWith(getThingsStart()); // Make sure the right action was dispatched.
  });
});

Lovely.

To break down what the test is doing...

jest.mock("react-redux", () => ({
  useSelector: jest.fn(),
  useDispatch: jest.fn()
}));

const mockUseSelector = useSelector as jest.Mock;
const mockUseDispatch = useDispatch as jest.Mock;
const mockDispatch = jest.fn();

These lines set up our mocked behaviour for useSelector, useDispatch and dispatch. We need to be able to mock implementations for useSelector and useDispatch and we need to spy on what dispatch was called with.

mockUseDispatch.mockImplementation(() => mockDispatch);
mockUseSelector.mockImplementation(callback =>
  callback({ thing: "this is our thing" })
);

These lines tell the useDispatch hook to return our mocked dispatch function and for the useSelector hook to call a callback containing a mocked state object.

const { result } = renderHook(() => useThing());

This line calls renderHook and tells it to run our useThing hook. renderHook returns a result object.

expect(result.current).toBe("this is our thing");
expect(mockDispatch).toHaveBeenCalledWith(getThingsStart());

Finally, we make our assertions! We first assert that the useThing hook returned the right value. Next we make sure that dispatch was called with the right action to dispatch.

Final thoughts

We now have a hook that we've concisely and confidently tested 🎉

I'm really happy with this pattern of testing hooks and I think that people should consider treating their hook tests more like their unit tests.

I'd love to hear any thoughts about this, so please feel free to reach out to me about it :)

-Dave

Injecting Mock Data Into Applications in $currentYear

Dave Cooper — Wed, 15 Jan 2020 09:03:48 +0000

Imagine this timeline... it's $currentYear and injecting mock data into web applications sucks. Keeping application state to be deterministic and flexible is incredibly difficult and cumbersome.

Oh wait, this is the timeline we live in 😱

Let's take a look at that in the most shameless abrasive way possible - with me shilling a library I wrote!

How do we currently get data into our applications for development?

Some of the things that I'm sure we've all tried when trying to mash data into our applications:

Connect the application to production services

No. Just don't.

If you do this, the developer police will come and take you to developer jail 🚓

In developer jail, you have to talk about "which IDE is the best" and Tabs vs. Spaces all day, every day. You don't want that and neither do I.

This only leads to problems. You'll accidentally mutate something on one (or all) of your users and everyone will be sad. Plus, you'll be in jail.

Connect the application to a UAT/Staging services

No.

If you do this, the developer police will also come and take you to developer jail 🚓

Inevitably, you'll end up having many people connecting to these services and user data will be mutated in weird ways that make it difficult to test new features or reprocuce bugs. As with the above scenario, everyone will be sad (and in jail - which will probably make you more sad).

Connect the application to a local copy of your services

This is the first approach that won't land you in developer jail.

However, it's a pain to do well - and if you don't do it well, you'll go straight to you-know-where.

You don't want to have to set your services up manually, so now you'll probably need to containerise (how do you even spell that word?) things and have ways to reliably reproduce your data stores from scratch and then when things change with your application architecture and implementation etc... you're probably going to have to do a lot of extra work to keep up with that.

Dave, all of these solutions suck so far. What else can I do?

Yes, yes they do. Let's continue...

Run a local mock service to expose data

Okay, we're getting somewhere.

We could write a really simple service (Node/Express servers are easy to set up and is generally familiar to frontend developers) to expose the endpoints and data that our application has. Writing a simple Node service isn't that hard and it doesn't put us in a spot where we can be touching actual customer data, nor are we going to be at risk of modifying something that someone else is relying on, since it's our own personal environment.

The downside here, though, is that we now have quite a lot of code to write and maintain when all we really care about is the data that comes back in response to our requests. We also still don't have easy ways of specifically and reliably testing happy/unhappy paths in our applications.

Dave, what about something off-the-shelf?

There are loads and loads and loads and loads and loads and loads (and loads) of solutions available to achieve exactly what we're talking about (did I mention there are loads of them?). Let's just look at a couple to see what they're like.

disclaimer: I don't want it to sound like I'm trash-talking anything that someone has put time and effort to develop. I'm merely pointing out the underlying problems with data injection that I see in web application development today.

json-server

json-server is a simple solution that allows you to specify a JSON file describing the endpoints of your application, and provides a HTTP interface to that. Boom 💥. Zero coding and easy to set up. It also has about a billion Github ⭐️'s so obviously it's doing a lot of things right.

Here's what a sample config looks like (shamelessly lifted from its Github page):

{
  "posts": [{ "id": 1, "title": "json-server", "author": "typicode" }],
  "comments": [{ "id": 1, "body": "some comment", "postId": 1 }],
  "profile": { "name": "typicode" }
}

Super easy to write. Super easy to understand. I'll let you guess what is returned when you make a GET to /comments (spoiler: you're correct).

There are some downsides to this:

What if I have a tonne of endpoints in my application?
- This file becomes quite large
How do I easily test happy/unhappy paths? (i.e. how do I test that my POST to /login has failed?)
How can I simulate delay into individual responses?
- There is a --delay flag you can pass into the process, but the delay is applied to all responses
Writing lots of JSON is a pain. You get little auto-complete and no typings on anything.

apimocker

I wanted to give some code examples for apimocker but to come up with a self-contained example that demonstrates basic usage is a bit lengthy, so I'll leave that up to you to check out on its Github page. Essentially, it's a beefier version of json-server.

apimocker allows for things like:

Switch-responses based on URL parameters (this is a term I like to refer to as scenarios - remember this for later)
Splitting of responses into files
Global response delay, or endpoint-specific response delay

This is all very cool 😎, except that these config files become very large, very quickly and can be quite hard to read. For example, to configure more advanced switch-responses (scenarios - keep remembering this term!) you need to know JSON path, which is like XPath, only more annoying (okay, that's subjective).

These solutions are still a bit heavy and a bit cumbersome, in my opinion. In these cases, we're spining up a new process and having that constantly run. My dev laptop is a fairly new Macbook, but it still sounds like it's about to launch into orbit any time I look at it.

Wouldn't it just be nice to have some way of not writing these messy, sometimes complicated configs and save on machine resources?

Hmmm 🤔

Enter data-mocks

Here's the part where I shamelessly plug a library I've written. I bet you've been looking forward to this!

I co-authored a library called data-mocks. It's very rad - but of course I'd say that...

Here's a brief overview of what it is/does:

Uses a code driven config to define endpoints we want to mock, and their respective responses
Similar to angular-multimocks, but framework agnostic
- This means it'll work with plain JS, Angular, React, React Native etc...
- This library was actually the inspiration for writing data-mocks
Compatible with XHR and Fetch
Light and easy to set up
Scenario (he said that term again!) support

Under the hood, data-mocks intercepts HTTP requests your application makes, based on a regex performed against the URL that is being requested. No actual HTTP requests get made as they are picked up by fetch-mock for Fetch requests and xhr-mock for XHR requests. The authors of those two libraries are the real MVPs here and deserve massive amounts of respect 🏆

Let's look at a basic React app that makes a request to an API:

App.jsx

import React from "react";
import ReactDOM from "react-dom";

import { SomeComponent } from "./SomeComponent";

ReactDOM.render(<SomeComponent />, document.getElementById("app"));

SomeComponent.jsx

import React, { Component } from "react";

export class SomeComponent extends React.Component {
  state = {
    thing: undefined
  };

  componentDidMount() {
    fetch("www.davesapi.com/get-my-thing").then(thing =>
      this.setState({ thing })
    );
  }

  render() {
    return (
      <>
        <h1>Dave's cool thing</h1>
        Here's a thing: {!this.state.thing ? "Loading..." : this.state.thing}
        {!this.state.thing === "badThing" ? null : (
          <h1>OH NO, THAT IS A BAD THING!</h1>
        )}
      </>
    );
  }
}

When the component loads, we hit our server and we display our thing once it comes back.

Neato burrito 🌯

But what if something bad (i.e. badThing) comes back from the API? 🤔

We could:

Hardcode our server to respond with badThing? ❌
- That would suck and is way too manual
Hardcode the response in our component? ❌
- That would also suck and is also way too manual
Use data-mocks? ✅

Introducing data-mocks into an application is very simple.

All a mock is, is the following:

A URL matcher, which is just a regex on the endpoint name
A HTTP method
A response object
A response code
A delay, in milliseconds

That's it. Five things to describe literally any mock. No JSON config. No having to learn a massive API or read a massive readme (although there is one available...).

All we need to do is call the injectMocks function exposed by data-mocks and pass in a list of mocks we want to use. Very neat.

App.jsx

import React from "react";
import ReactDOM from "react-dom";

import { SomeComponent } from "./SomeComponent";

import { injectMocks } from "data-mocks";

const mocks = {
  default: [
    {
      url: /get-my-thing/,
      method: "GET",
      response: { thing: "this is a thing" },
      responseCode: 200,
      delay: 250
    }
  ]
};

injectMocks(mocks, "default"); // This sets the default scenario

ReactDOM.render(<SomeComponent />, document.getElementById("app"));

Sick - we're good to go. We can now run our app locally and we get the same behaviour as we did when we were connecting to the actual service.

But I promised you better than that - I promised you an easy way to test other paths of use in the app.

Scenarios

We can now talk about them! 🕺💃

A scenario is just a mapping of responses that is given a name (i.e. the scenario you are running). The default scenario is the default set of behaviour exhibited by endpoints in the application. Any non-default scenario will give you the full set of default mocks, plus all mocks defined in the scenario. If a mock has the same URL matcher in the specified scenario, it will override the response in the corresponding default mock.

In simpler terms:

A scenario is a set of API responses you want your application to give in a given scenario (yes, we've used the term to define the term).

Let's see what this looks like:

App.jsx

import React from "react";
import ReactDOM from "react-dom";

import { SomeComponent } from "./SomeComponent";

import { injectMocks, extractScenarioFromLocation } from "data-mocks";

const mocks = {
  default: [
    {
      url: /get-my-thing/,
      method: "GET",
      response: { thing: "thisIsAThing" },
      responseCode: 200,
      delay: 250
    }
  ],
  badThing: [
    {
      url: /get-my-thing/,
      method: "GET",
      response: { thing: "badThing" },
      responseCode: 200,
      delay: 250
    }
  ]
};

injectMocks(mocks, extractScenarioFromLocation(window.location));

ReactDOM.render(<SomeComponent />, document.getElementById("app"));

You're probably getting the idea here. However, two things will probably stick out:

"When I run this, I still get the default scenario respone. What gives?"
"What is this extractScenarioFromLocation(window.location) business?"

To answer both at once: we need to specify which scenario to run. The way we do this is through the URL of the page we're on. Go on, add ?scenario=badThing to your query string (i.e. localhost:8080?scenario=badThing). If you have another way that you'd like to pass in the scenario name to the injectMocks function, feel free to not use the extractScenarioFromLocation util function.

You'll now see that we get the unhappy path response from our mocks.

This is especially helpful when running things like Cypress tests - as we don't need to change anything at all in our code to test different behaviours and make assertions based on what comes back from our APIs!

Other considerations

There are a couple of things to keep in mind with this approach that will make life nice and easy for you:

You can avoid having mocks bundled into your application by surrounding the call to injectMocks with a if (process.env === 'development') { injectMocks(...); } block.
- Alternatively you can define a separate entry point into your application (i.e. App.dev.jsx) and point your dev build to there. This is a bit more work, though.
You can move your mock definitions into their own section of the project (i.e. /mocks) to avoid clutter in the entry point of your application

Summary of what this allows us to do

With all of the above, we can now:

Easily integrate new mocks into the application
Easily toggle between our new best friend, scenarios
- This allows us to test feature/bug fixes when developing and in automated UI tests. This is the killer feature of data-mocks, in my opinion. Nothing else seems to offer something as easy (in terms of configuring and using the feature)
Write frontend code without having to have a single line of backend code (or a mock API server) written
Not have to write yet another JSON config

There you go, now we're data-mock'ing!

If you've got any questions about this or want to contribute, please ping me or open a PR/Github issue 😊

-Dave