13 / 13

How do you test reducers created with createSlice()?

Testing Reducers Created with createSlice in Redux Toolkit

Reducers created with createSlice() can be easily tested by calling them directly with an initial state and an action. Since reducers are pure functions, you can verify that they produce the expected next state for a given input without needing to mock a Redux store.

Steps to Test Reducers
  1. 1

    Import the reducer and its action creators from the slice file.

  2. 2

    Provide an initial state and simulate actions by dispatching them manually.

  3. 3

    Assert that the returned state matches the expected output.

  4. 4

    Ensure that reducers do not mutate the original state (immutability test).

Example: Testing a createSlice Reducer

By testing reducers in isolation, you ensure the logic for state transitions works correctly, making your Redux application more predictable and maintainable.

Difficulty: 5/10
Topics: unit testing, createSlice reducers, mock store

Scenario Questions

0-2 years experience
  1. 1

    You have a slice created with createSlice that manages a list of todos. Walk me through how you would write a unit test for the reducer that handles the addTodo action.

  2. 2

    If your test shows that the state after dispatching removeTodo is unchanged, what common mistakes could cause that failure?

  3. 3

    How would you set up the initial state in a test to verify that the toggleCompleted reducer correctly flips the completed flag?

2-5 years experience
  1. 1

    We need optimistic updates for a fetchPosts async thunk. How would you test that the pending, fulfilled, and rejected extraReducers correctly update loading and error flags?

  2. 2

    During a code review you notice a reducer mutates nested objects directly. Explain how you would catch this in tests and why it matters with Redux Toolkit’s Immer.

  3. 3

    Our CI pipeline is flaky when reducer tests rely on Date.now(). How would you make those tests deterministic?

5-8 years experience
  1. 1

    Our app has dozens of slices and shares a common test utility. Describe how you’d design a reusable helper that validates immutability, action payload typing, and state shape across slices.

  2. 2

    We observed performance regressions after adding a large normalized entity slice. How would you test that bulk‑update reducers (e.g., upsertMany) maintain O(1) updates and avoid unnecessary re‑renders?

  3. 3

    When integrating RTK Query with slice reducers, we need to ensure cache‑invalidation actions are handled correctly. How would you structure tests to cover interactions between slice reducers and RTK Query’s cache lifecycle?

8+ years experience
  1. 1

    Our organization is migrating legacy Redux code to Redux Toolkit. What strategy would you propose for testing existing reducers versus new createSlice reducers to ensure behavior parity and minimize risk?

  2. 2

    Multiple teams share a common store configuration and testing framework. How would you establish guidelines and tooling to enforce consistent reducer testing practices, including edge cases like non‑serializable payloads?

  3. 3

    We plan to allow third‑party modules to inject their own slices at runtime. What testing architecture would you put in place to verify that dynamically added reducers integrate correctly without breaking existing state contracts?

Follow-up Questions

  • What assertions do you add to guarantee the state wasn't mutated?
  • How would you mock async thunks when testing extraReducers?
  • Can you sketch a reusable test utility you’d create for slice reducers?