Forem: Patrick Geiger

React and TypeScript Testing: Mocking Functions with Jest

Patrick Geiger — Tue, 07 Apr 2020 13:36:23 +0000

Hello, in this article we're going to talk about mocking functions with Jest and TypeScript in React. Specifically, we're going to talk about how to mock a function that you pass into a component using Jest.

Now mocking functions with Jest, in general, is pretty straightforward.

const mockFunction = jest.fn();

That's all you really need to get started using a mock function that you can then monitor. For example, if pushing a button should call a function your assertion, after clicking the button, can be the following:

expect(mockFunction).toHaveBeenCalledTimes(1);

This is, of course, for functions that are being passed into your component. So, if using Enzyme, your code may look like this:

const mockFunction = jest.fn();
const wrapper = mount(<MyComponent onChange={mockFunction} />);

This works fine for the most part. But this does type things with any, plus what do you do if you need create a variable but don't want to initialize it immediately? You have to type it of course, but what typing do you use? Consider the following:

let mockFunction: jest.Mock<any, any>;

This would work fine in the following case:

let mockFunction: jest.Mock<any, any>;
let wrapper: ReactWrapper;

beforeEach(() => {
  wrapper = mount(<MyComponent onChange={mockFunction} />);
});

In some cases, this is about as far as you need to go. After all, the function itself is fake anyway. Typing it further may not be necessary depending on your use case. But it'd be good form to make sure it's properly typed and you're not using any. You may even need it to be typed because it provides useful information, or you get a linting error because of it. So how would we go about doing that?

It's actually relatively straightforward. I'll break it down:

Looking at jest.mock<any, any>, the jest.mock part stays. As for the <any, any> it's helpful to look at it as <return, input>. The first value is what you plan on returning, while the second value is actually an array of the inputs. So what if we take in a string and return nothing?

let mockFunction: jest.Mock<void, [ string ]>;

It's simple once you know what goes where. Let's see it in action when it comes to assignment:

let mockFunction: jest.Mock<boolean, [string]>;

mockFunction = jest.fn((myString: string) => {
  return true;
});

In the above case we threw in a return value. Sometimes it's necessary to mock a return when you're testing. After all, you don't really care how the function got the return. These unit tests are for this component in particular, and whatever function is being passed in, in the actual code, should have its own unit tests. So you just need your return so you can move on.

Let's take a look at a more complicated example, this time with promises.

Consider that you have a voting component. The component itself consists of two buttons that allow the user to like or dislike something. You need to persist this on the back end as well. One solution to this is to pass a function into the voting component that talks to the back end in some way. There may be better solutions, but for the sake of this example we're going to go with this one.

The exact implementation isn't important. Let's just say the function that talks to your back end takes in an string id and a boolean value, and returns a Promise and this function is passed in through an onChange prop on the component. That onChange prop is then called when one of the buttons are clicked.

interface IResponse {
  status: "SUCCESS" | "ERROR";
}

let mockFunction: jest.Mock<Promise<IResponse>, [string, boolean]>;

let wrapper: ReactWrapper;

beforeEach(() => {
  mockFunction = jest.fn((id: string, vote: boolean) =>
    Promise.resolve({ status: "SUCCESS" })
  );

  wrapper = mount(<Votes onChange={mockFunction} />);
});

Of course your IResponse should probably be in its own typescript file. Regardless, this is the basic structure you would use for something like this. If you wanted to test your error handling when receiving an error from the backend, you can just switch the status over to "ERROR". And if you wanted to test the promise failing entirely, you can use reject instead of resolve.

Hopefully this helped somebody out there.

React Unit Testing: Async Act

Patrick Geiger — Fri, 20 Mar 2020 17:37:07 +0000

This is more or less for my own benefit as much as other people. Since starting my newest job last September, I've been knee deep in figuring out React testing with Enzyme and Jest. I'm not saying what I've got is the best way of doing things, but it works well enough.

So this will be the first of a series of different short articles where I describe methods of unit testing React.

We'll start with the async act. Act itself is rolled into a lot of Enzyme functions already, for example mount and simulate. So for the most part it's abstracted out if you use Enzyme.

But Enzyme just rolls in act, which is required if state changes happen. Without encompassing something that changes state in your component in act in a unit test, it throws an error. There are situations where you need to wait until the state change is entirely finished before continuing on. This is often found when using useEffect and setting state in that, especially if it sets the state that's required for the rest of the component. If you start looking at the component before useEffect has run its course, you might run into issues with things not looking how you'd expect them to.

This is where async act comes in.

import React from "react";

import { mount } from "enzyme";
import { act } from "react-dom/test-utils";

import MyComponent from "./MyComponent";

let wrap;
beforeEach(async () => {
  await act(async () => {
    wrap = mount(<MyComponent />);
  });
  wrap.update();
});

Let's pretend that MyComponent has a useEffect that sets some state. If you just use mount that state may not be set properly. On the other hand, if you use an async act like above? It will wait until the useEffect has finished running.

Make sure to call .update() as well so the React wrapper updates.

This was a major pain point for us where useEffects would not run as we expected them to. The async act solved a lot of these issues, and we didn't even know it existed until we updated our version of React. So I guess that's a good lesson for keeping up with the updates for the tools you use!

Udacity Full-Stack Nanodegree Journey

Patrick Geiger — Tue, 25 Feb 2020 20:55:56 +0000

Hey, this is my first post. I'm sure I'll post about other things, but I thought a great way to start on this platform is to document my journey through Udacity's Full-Stack Nanodegree.

I'd like to preface all of this by saying I have CS degree and some experience in the software engineering already. Currently, I do a lot of front end work in TypeScript and React at my job with some back end JavaScript work thrown in so I'm not a beginner. With that said, I do want to expand my skill set and learn more about the back end, as I think that's where I'm weakest.

So for the foreseeable future I'll be documenting what I learn from the Nanodegree, my work on the projects in the Nanodegree, and my general thoughts on the structure of it all. I haven't decided if I'm going to do an update once every week or every two weeks, but I'm sure I'll figure that out as we go.

Looks like the first project is some sort of CRUD application with the purpose of "connecting musicians with venues" and it seems pretty straightforward. Here's the tech stack for it:

Out of the above, I've worked with Python 3, PostgresSQL, and psycopg2. I sadly haven't done anything with Flask in the past, so the project should be a good learning experience. I briefly dabbled with Django, though.

I look forward to learning more, and hopefully posting more too. I'm not entirely sure if I'm just going to offer snippets of my journey or do full recaps at regular intervals. We'll see.