Redux Testing Lessons Learned: Render Components with a Real Store
Tags: react, redux, webdev, testing
Published: 2021-11-23 22:19:33

This post is a follow up to [Redux Testing: Hard Lessons Learned](https://dev.to/xjamundx/redux-testing-hard-earned-lessons-learned-1o9e) where I spoke about two important principles for testing redux apps: "Stop Testing your Disconnected Components" and "Build a Small Utility Library". Mostly we went through some of the key utilities that I use to make testing redux apps more manageable. This post will cover another area I called out in the first post: **Render Components with a Real Store**

For a long time I relied on [redux mock store](https://github.com/reduxjs/redux-mock-store) to preload data into my components for rendering during tests. This approach makes it easy to take a snapshot of a component with arbitrary data and ensure that it renders correctly. Where it completely fails is testing interactions.

What happens when I click the close the button or when I select that image? With redux mock store you have a special method named [getActions](https://github.com/reduxjs/redux-mock-store#synchronous-actions) that tells you what actions were fired, but that's it. Those actions don't actually make it to your reducers and they never update the UI. This makes your tests pretty frustrating to write. There's no good way to confirm that a component can transition from one state to another. You can only test snapshots.

The first and quickest way to solve this is to pass your actual redux store into the `<Provider>` you use to wrap your tests and then return it. For example:

```tsx
import { render } from "@testing-library/react";
import { store } from "../app/store";

function renderWithContext(element) {
    render(
      <Provider store={store}>{element}</Provider>
   );
   return { store };
}
```

This immediately gives you all kinds of powers. The first one is the ability to dispatch actions to populate or otherwise your modify redux store. Because those actions are dispatched synchronously you can immediately assert that the UI was updated.

```tsx
test("table should render all kinds of data", () => {
    const { store } = renderWithContext(<ResultsTable />);
    // expect() table to be empty
    store.dispatch({ type: "POPULATE_DATA", data: { /* ... */ })
    // expect() table to be full
});
```

The other thing it lets you do is assert that your redux store changed in response to an event that wouldn't normally affect the component you are testing. For example let's say you had a button that updated a counter, but that counter component lived somewhere else. We can pretty easily test that clicking the button updated the count in our store.

```tsx
test("counter should update count", () => {
    const { store } = renderWithContext(<CounterButton />);
    expect(store.getState().count).toEqual(0);
    userEvent.click(screen.getByRole("button"));
    expect(store.getState().count).toEqual(1);
});
```

Now the issue with sharing your actual redux store is that the order of your tests shouldn't matter. You really want to run your tests in isolation. With the shared store approach if you dispatch an event in one test, the changes are propagated to all future tests. And that's why I ended up with the `getStoreWithState` method I showed in [my previous article](https://dev.to/xjamundx/redux-testing-hard-earned-lessons-learned-1o9e) as a key utility.

```tsx
// ...
export const store = configureStore({ reducer });
export function getStoreWithState(preloadedState) {
  return configureStore({ reducer, preloadedState });
}
```

There are two important parts here. The one that I mentioned before was the `preloadedState` option, which lets us render components in tests with state already setup in a specific way (similar to mock redux store). The second and more subtle accomplishment here is that we're giving our generated store access to the same reducers used by our app's store. This gives us an isolated store to use for each test that also has access to the full power of our application's reducers.

One benefit of this approach is that every time we test a component hooked into redux, we're also testing multiple reducers. It more economical and it more accurately reflects how our application actually works. Not to mention your tests are way easier to write this way. If you're used to testing with mock-redux-store this approach is going to give you a huge boost.

If you want to learn more about my approach to testing redux applications please watch my course [Confidently Testing Redux Applications with Jest and TypeScript](https://egghead.io/courses/confidently-testing-redux-applications-with-jest-typescript-16e17d9b).