Unit Testing Reducers
By: Jan Hesters
Tags: State, Reducer, Riteway, Unit Testing, Redux

The tests in the examples are written with RITEway because it has a genius API that forces you to write good tests. RITEway only exposes an equality assertion, which is perfect for testing pure functions. (The examples work with Jest, too. 🃏)

I’ll let you read the code now first, and afterwards we analyse the structure of the tests.

In the example above, we combined the logic and the tests. Usually, the code would live in at least three files ( counter-reducer.js , counter-reducer.test.js and root-reducer.js ):

src/

├── ...

├── features/

│ ├── ...

│ └── counter/

│ ├── ...

│ └── counter-reducer.js

│ └── counter-reducer.test.js

├── redux/

│ ├── root-reducer.js

│ ├── root-saga.js

│ └── store.js

└── index.test.js

The first test ensures the reducer has the correct initial state. Use a createState factory function for this test and avoid exporting the initial state and using it for the assertion.

You need to ensure the initial state is correct before you use it in your tests. If you export it and use it in your assertion, an error might slip through. The initial state could have wrong keys, or the wrong initial values for correct keys or be missing keys and your tests would still pass.

The first test tests the reducer without arguments. A reducer that returns its initial state when called without arguments is not in Redux’ official reducer specification. However, it’s helpful for selector tests (- we will see below exactly how -) or to populate initial state for the useReducer Hook.

const [state, dispatch] = useReducer(reducer, reducer());

Suppose you can’t call your reducers without arguments (for example because you’re using Redux Toolkit). In that case, you can write this test by passing undefined and an empty object.

assert({

given: 'no state with an empty action',

should: 'return the valid initial state',

actual: reducer(undefined, {}),

expected: createState(),

});

Note: If you are looking for an alternative to Redux Toolkit that supports empty argument reducers, check out Autodux.

Test the action creators tightly coupled to your reducer by invoking both in your tests. Avoid action creator tests that assert on their returned action object because all you care about is how they modify the state of your reducer. Using action creators and their handlers together is the most efficient and effective way to test action creators and reducer functions.

Use a factory function like createState to set up the tests for action creators. (For selectors, directly use the rootReducer in conjunction with your actions to compose the state.) You can easily debug the factory function, which allows you to describe the exact state shape that you want. Favor a factory function over inlining the reducer's complete state because it's shorter to overwrite the relevant keys. Avoid using actions creators in the setup for your action creator tests because you don't know whether they behave correctly at that point. Sometimes (e.g. for complex reducers with many keys) you should additionally use a createPopulatedState factory function.

const createPopulatedState = ({

count: 14

/* , ... more populated values for more keys */

} = {}) => createState({ count /* , ... more keys */ });

Furthermore, notice how the action creators are tightly coupled to their actions and the case statements, so there is no need to worry about importing or using the right constant. If you have an action creator, you have its type (via incrementBy.type , or incrementBy().type - the former is compatible with thunks).

You should always write at least two tests for each action creator. One to test how it affects the reducer with no prior state (= initial state), and one to test how it interacts with existing state (of the same slice, obviously). (Sometimes you need more than one test for the “with state” scenario.)

Using createPopulatedState you can simplify your "with existing state" action creator test cases.

And best of all, if your action creator tests pass, you know that they change the state the way you intended. At this point, it’s okay to use them in your selector tests to set up state. You also want to test the selectors with your rootReducer . (For local state with useReducer , you replace rootReducer with the reducer you're testing.) Using selectors in conjunction with action creators and your rootReducer gives you confidence that:

You hooked up your reducer to your rootReducer , and you did it correctly. Your action creators work when interacting with each other (- if you use several to set up the test). Your selectors return the correct value.

You should test selectors with at least two cases, too: One with default state and one with the desired populated state. For the default state, you can call the rootReducer without arguments to get the global initial state. And again, if you can't call your rootReducer without arguments to produce the default state (for example because you're using Redux Persist), you can create and export the rootState from your root-reducer.js file.

To test the selector’s behavior with state, you can create an actions array and reduce over it to build up the state. This is an excellent technique because it works well even if your reducer depends on several pieces of state controlled by multiple actions (and slices e.g. setOffset ).

If you liked this article, you might want to follow me on Twitter and checkout janhesters.com because there is more.