Best practices in mocking React components aren’t entirely unheard of, even in connection with a Redux state, and even not in connection with the quite convenient Hooks description ({ useSelector, useDispatch}).
So, of course the knowledge of a proper approach is at hand. And in many scenarios, it makes total sense to follow their principle of exactly arranging your Redux state in your test as you would in your real-world app.
Nevertheless, there are reasons why one wants to introduce a quick, non-overwhelming unit test of a particular component, e.g. when your system is in a state of high fluctuation because multiple parties are still converging on their interfaces and requirements; and a complete mock would be quite premature, more of a major distraction, less of being any help.
Proponents of strict TDD would now object, of course. Anyway – Fortunately, the combination of jest with React Testing Library is flexible enough to give you the tools to drill into any of your state-connected components without much knowledge of the rest of your React architecture*
(*) of course, these tests presume knowledge of your current Redux store structure. In the long run, I’d also consider this bad style, but during highly fluctuatig phases of develpment, I’d favour the explicit “this is how the store is intended to look” as safety by documentation.
On a basic test frame, I want to show you three things:
- Mocking useSelector in a way that allows for multiple calls
- Mocking useDispatch in a way that allows expecting a specific action creator to be called.
- Mocking useSelector in a way that allows for mocking a custom selector without its actual implementation
(Upcoming in a future blog post: Mocking useDispatch in a way to allow for async dispatch-chaining as known from Thunk / Redux Toolkit. But I’m still figuring out how to exactly do it…)
So consider your component e.g. as a simple as:
import {useDispatch, useSelector} from "react-redux";
import {importantAction} from "./place_where_these_are_defined";
const TargetComponent = () => {
const dispatch = useDispatch();
const simpleThing1 = useSelector(store => store.thing1);
const simpleThing2 = useSelector(store => store.somewhere.thing2);
return <>
<div>{simpleThing1}</div>
<div>{simpleThing2}</div>
<button title={"button title!"} onClick={() => dispatch(importantAction())}>Do Important Action!</button>
</>;
};
Multiple useSelector() calls
If we had a single call to useSelector, we’d be as easily done as making useSelector a jest.fn() with a mockReturnValue(). But we don’t want to constrain ourselves to that. So, what works, in our example, to actually construct a mockin store as plain object, and give our mocked useSelector a mockImplementation that applies its argument (which, as selector, is a function of the store)) to that store.
Note that for this simple example, I did not concern myself with useDispatch() that much. It just returns a dispatch function of () => {}, i.e. it won’t throw an error but also doesn’t do anything else.
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import TargetComponent from './TargetComponent;
import * as reactRedux from 'react-redux';
import * as ourActions from './actions';
jest.mock("react-redux", () => ({
useSelector: jest.fn(),
useDispatch: jest.fn(),
}));
describe('Test TargetComponent', () => {
beforeEach(() => {
useDispatchMock.mockImplementation(() => () => {});
useSelectorMock.mockImplementation(selector => selector(mockStore));
})
afterEach(() => {
useDispatchMock.mockClear();
useSelectorMock.mockClear();
})
const useSelectorMock = reactRedux.useSelector;
const useDispatchMock = reactRedux.useDispatch;
const mockStore = {
thing1: 'this is thing1',
somewhere: {
thing2: 'and I am thing2!',
}
};
it('shows thing1 and thing2', () => {
render(<TargetComponent/>);
expect(screen.getByText('this is thing1').toBeInTheDocument();
expect(screen.getByText('and I am thing2!').toBeInTheDocument();
});
});
This is surprisingly simple considering that one doesn’t find this example scattered all over the internet. If, for some reason, one would require more stuff from react-redux, you can always spread it in there,
jest.mock("react-redux", () => ({
...jest.requireActual("react-redux"),
useSelector: jest.fn(),
useDispatch: jest.fn(),
}));
but remember that in case you want to build full-fledged test suites, why not go the extra mile to construct your own Test store (cf. link above)? Let’s stay simple here.
Assert execution of a specific action
We don’t even have to change much to look for the call of a specific action. Remember, we presume that our action creator is doing the right thing already, for this example we just want to know that our button actually dispatches it. E.g. you could have connected that to various conditions, the button might be disabled or whatever, … so that could be less trivial than our example.
We just need to know how the original action creator looked like. In jest language, this is known as spying. We add the blue parts:
// ... next to the other imports...
import * as ourActions from './actions';
//... and below this block
const useSelectorMock = reactRedux.useSelector;
const useDispatchMock = reactRedux.useDispatch;
const importantAction = jest.spyOn(ourActions, 'importantAction');
//...
//... other tests...
it('dispatches importantAction', () => {
render(<TargetComponent/>);
const button = screen.getByTitle("button title!"); // there are many ways to get the Button itself. i.e. screen.getByRole('button') if there is only one button, or in order to be really safe, with screen.getByTestId() and the data-testid="..." attribute.
fireEvent.click(button);
expect(importantAction).toHaveBeenCalled();
});
That’s basically it. Remember, that we really disfigured our dispatch() function. What we can not do this way, is a form of
// arrangement
const mockDispatch = jest.fn();
useDispatchMock.mockImplementation(() => mockDispatch);
// test case:
expect(mockDispatch).toHaveBeenCalledWith(importantAction()); // won't work
Because even if we get a mocked version of dispatch() that way, the spyed-on importantAction() call is not the same as the one that happened inside render(). So again. In our limited sense, we just don’t do it. Dispatch() doesn’t do anything, importantAction just gets called once inside.
Mock a custom selector
Consider now that there are custom selectors which we don’t care about much, we just need them to not throw any error. I.e. below the definition of simpleThing2, this could look like
import {useDispatch, useSelector} from "react-redux";
import {importantAction, ourSuperComplexCustomSelector} from "./place_where_these_are_defined";
const TargetComponent = () => {
const dispatch = useDispatch();
const simpleThing1 = useSelector(store => store.thing1);
const simpleThing2 = useSelector(store => store.somewhere.thing2);
const complexThing = useSelector(ourSuperComplexCustomSelector);
//... whathever you want to do with it....
};
Here, we want to keep it open how exactly complexThing is gained. This selector is considered to already be tested in its own unit test, we just want its value to not-fail and we can really do it like this, blue parts added / changed:
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import TargetComponent from './TargetComponent;
import * as reactRedux from 'react-redux';
import * as ourActions from './actions';
import {ourSuperComplexCustomSelector} from "./place_where_these_are_defined";
jest.mock("react-redux", () => ({
useSelector: jest.fn(),
useDispatch: jest.fn(),
}));
const mockSelectors = (selector, store) => {
if (selector === ourSuperComplexCustomSelector) {
return true; // or what we want to
}
return selector(store);
}
describe('Test TargetComponent', () => {
beforeEach(() => {
useDispatchMock.mockImplementation(() => () => {});
useSelectorMock.mockImplementation(selector => mockSelectors(selector, mockStore));
})
afterEach(() => {
useDispatchMock.mockClear();
useSelectorMock.mockClear();
})
const useSelectorMock = reactRedux.useSelector;
const useDispatchMock = reactRedux.useDispatch;
const mockStore = {
thing1: 'this is thing1',
somewhere: {
thing2: 'and I am thing2!',
}
};
// ... rest stays as it is
});
This wasn’t as obvious to me as you never know what jest is doing behind the scenes. But indeed, you don’t have to spy on anything for this simple test, there is really functional identity of ourSuperComplexCustomSelector inside the TargetComponent and the argument of useSelector.
So, yeah.
The combination of jest with React Testing Library is obviously quite flexible in allowing you to choose what you actually want to test. This was good news for me, as testing frameworks in general might try to impose their opinions on your style, which isn’t always bad – but in a highly changing environment as is anything that involves React and Redux, sometimes you just want to have a very basic test case in order to concern yourself with other stuff.
So, without wanting that you lower your style to such basic constructs, I hope this was of some insight for you. In a more production-ready state, I would still go the way as that krawaller.se blog post state above, it makes sense. I was just here to get you started 😉
Schneide Blog 