![redux-toolkit-testing-async-actions](/assets/img/0_idwszkuxnyjmy7vh.jpeg 'redux-toolkit-testing-async-actions')

Hello everyone 👋,
this post is a continuation of our testing saga with redux-toolkit, here we will continue our previous post now focusing on testing our async actions.

in case you haven't read the previous post I recommend you give it a read because we'll be here using the same application and increasing our test coverage ✅.

## Creating the API with JSON Server

Now let's make a real call to our endpoint, for that, I'm going to use a tool called `JSON Server` that allows us to create an API in less than 30 seconds.

Let's create an endpoint called `/results` which will return our list of items,
to do that we will create a file called 'db.json' in the root level of our project, and .

```json
{
  "results": [
    {
      "id": 0,
      "price": 88782,
      "review": 96323,
      "rating": 43708,
      "distance": 38824,
      "place": "Daytona Beach",
      "name": "Rafael Oberbrunner",
      "image": "https://a0.example.com/image0.jpg"
    }
    // .....
  ]
}
```

Then in our package.json we will create a new script to start the API server.

```sh

"scripts": {
    "start": "react-scripts start",
    ...
    "start:server": "json-server --watch db.json --port 3001" // 👈 here we are using json-server in the port 3001
  },
```

## Testing Async Actions

if you've created an application with redux in the past, you are probably already familiar with the concept of `thunks` and using tools like `redux-mock-store` to create a mock from the store

although functional this approach brings a series of other problems, you have to configure a store along with middleware, the problem is here is when we need to test 'async' actions, and unless your application does not receive any external information, at some point you will have to interact with some API, test this case just with mock is not ideal,

> if you still use `redux-mock-store` an approach that does sense and adopts dependency injection, for libs that make API call

That being said, seeing how the ReactJS ecosystem has changed a lot in recent years, today we have tools like `react-testing-library` that encourages us to think under **integrated tests** let's look here at how they work in practice.

first, let's create our render helper to make our tests easier

```typescript
// testUtils.jsx
import React from 'react'
import { render as rtlRender } from '@testing-library/react'
import { configureStore } from '@reduxjs/toolkit'
import { Provider } from 'react-redux'

import homeReducer from './features/home/HomeSlice'

const render = (
  ui: React.ReactElement,
  {
    initialState,
    store = configureStore({
      reducer: { home: homeReducer },
      preloadedState: initialState,
    }),
    ...renderOptions
  } = {}
) => {
  function Wrapper({ children }: { children: React.ReactNode }) {
    return <Provider store={store}>{children}</Provider>
  }
  return {
    ...rtlRender(ui, { wrapper: Wrapper, ...renderOptions }),
    // adding `store` to the returned utilities to allow us
    // to reference it in our tests (just try to avoid using
    // this to test implementation details).
    store,
  }
}

export * from '@testing-library/react'

export { render }
```

note here we are using our real store,

the second step is to configure \`msw\` to intercept the \`API\` calls in our case here we are going to intercept the call to `/results`
let's go ahead and create a new test file for our integration tests, which we can call `Home.spec.tsx`

```typescript
// Home.spec.tsx
import { rest } from 'msw'
import { setupServer } from 'msw/node'
import { resultsMock } from '../../mocks/results'
import { render, screen, fireEvent } from '../../test-utils'

import Home from './Home'

const { click, change } = fireEvent
const { queryByText, getByText, getByTestId, getAllByTestId } = screen

const BASE_URL = 'http://localhost:3001'

export const handlers = [
  rest.get(`${BASE_URL}/results`, (_, res, ctx) => {
    return res(ctx.json(resultsMock), ctx.delay(150))
  }),
]

const server = setupServer(...handlers)
```

see that we have created a handle function that will intercept the call to /results and return our mock data, and we have also added a delay to simulate a slow network connection, we also destructure the \` click\` and \` change\` events from \`fireEvent\` and \`screen\` to make our tests more readable.

next, we will create a test that will make sure that the API call is being made correctly, and we will also check that the results are being displayed correctly for that we will use our custom render to run the integration tests.

```typescript
// Home.spec.tsx

import { rest } from 'msw'
import { setupServer } from 'msw/node'
import { resultsMock } from '../../mocks/results' // mock file with the results simulated
import { render, screen, fireEvent } from '../../test-utils'

import Home from './Home'

const { click, change } = fireEvent
const { queryByText, getByText, getByTestId, getAllByTestId } = screen

const BASE_URL = 'http://localhost:3001' // base url for the API

export const handlers = [
  rest.get(`${BASE_URL}/results`, (_, res, ctx) => {
    return res(ctx.json(resultsMock), ctx.delay(150)) // delay to simulate a slow network connection
  }),
]

const server = setupServer(...handlers)

afterAll(() => server.close()) // close the server after all the tests
beforeAll(() => server.listen()) // start the server before all the tests
afterEach(() => server.resetHandlers()) // reset the handlers after each test

describe('Home component', () => {
  it('should show loading state', async () => {
    render(<Home />)
    expect(getByText(/loading../i)).toBeInTheDocument()
  })

  it('should show loading state', async () => {
    render(<Home />)
    await sleep(200)
    expect(queryByText(/loading.../i)).not.toBeInTheDocument()
    expect(getByText(/Yolanda Little/i)).toBeInTheDocument()
  })

  it('should filter results', async () => {
    render(<Home />)
    await sleep(200)
    change(getByTestId('search'), { target: { value: 'Beach' } })
    expect(getAllByTestId('location-name')).toHaveLength(2)
  })

  it('should show empty list when no results', async () => {
    render(<Home />)
    await sleep(200)
    change(getByTestId('search'), { target: { value: 'xxxx' } })
    expect(getByText(/No results found/i)).toBeInTheDocument()
  })

  it('should filter list by favorites', async () => {
    render(<Home />)
    await sleep(200)
    click(getByText(/Show Favorites/i))
    expect(getByText(/No results found/i)).toBeInTheDocument()

    click(getByText(/Show All/i))
    expect(getAllByTestId('location-name')).toHaveLength(3)
  })
})
```

Amazing 🎉 now our tests are passing, with that, we can check the results of our tests and see how the application behaves when we are interacting with it.



## Different Testing Philosophies

as we can see here the main difference in testing philosophy and that we have now inverted the concept of 'isolation' by not testing redux directly treating it as just an implementation detail what I find amazing with this approach is that we started to test real behavior of the application, thinking about how a user can interact with it, for users it doesn't matter which framework you use to connect with the API, or which action you create to make the request what matters most to the user is "when interacting in an X way I see a Y response"

creating tests like this brings us **great flexibility**, we can change these tools mentioned above without our tests needing to be changed forcing us to always test what matters in our code, and most importantly bringing us a **higher level of confidence** about our code.

## Recap

Boom app working, tests passing, really makes me feel so much more confident, and with that let's just recap some things we saw here in this post

1. for pure functions (reducers, selectors) we can use unit tests in isolation
2. for async actions, we can use tests integration

with the example we have now, it is easy to see that we can apply these two approaches in our applications, using isolated tests to test our actions and reducers, and use integrated tests to test our asynchronous flames, I find it amazing how testing culture has evolved on the frontend not long ago it was very rare to see tests in applications with javascript mostly because of the difficult setup, and now with tools like react-testing-library tests are not only common but also expected from applications like this.

if you made it this far, my heartfelt thanks, help me by sharing this post and tell me your opinion here, my goal is to share and learn so don't let it share and follow me on social networks that will be here in short.

Redux Toolkit how to test async actions using React Testing Library and MSW

Redux Toolkit Testing Async actions

![redux numbers](/assets/img/002.jpg 'Redux download numbers')

I was reading some articles about the 'redux evolution', and it makes me happy to see that in 2022 redux remains quite relevant, and not only relevant also still hitting download numbers in the house of 7,000,000 per week.

Being so widespread and so popular, you might think that until now, no one would have had a hard time testing redux/RTK apps, but as I was doing some research with the developer community I realised that a lot of people still don't know how to write tests for cases like `reducers`, `asynchronous actions`, `selectors`, `middlewares`, etc.

Taking advantage of this and also the fact that many people asked me to make a post about tests with `Redux ToolKit (RTK)`, I decided to launch my new blog✨ and talk a little about this subject.

# Tests with Redux

Whoever has already come from an application with `react-redux`, must already be very familiar with the benefits of taking a functional approach and testing your application in "isolation" testing reducers and action creators for example.

Let's think of a simple Airbnb-style application where we will have a page with the list of results, where we can filter them by name, and favorites.

![Application](/assets/img/appdemo.gif 'app demo')

For that project we will use those technologies:

- React as a UI Language
- Redux as state manager
- TailwindCss UI as our design toolkit
- Redux Toolkit as a Data Flow Framework
- Jest: A testing framework for JavaScript.
- React Testing Library: A testing framework for React.

> by the way I'm planning a post here to talk a little about `Tailwindcss` let me know if you would be interested

# Project Structure

You can find a link to the project repository [here](https://github.com/rocketseat-experts-club/redux-toolkit-testing-30-03-22)
please feel to browse, it will make it easier to follow this post
and if you have any questions or suggestions feel free to contact me.

The project structure is as follows:

```sh
src
├── App.tsx // the main component
├── app
│   ├── hooks.ts
│   └── store.ts
├── components // general components
│   ├── HeartIcon.tsx
│   ├── Map.tsx
│   ├── Search.tsx
│   └── SearchIcon.tsx
├── features
│   └── home // the home page module
│       ├── Home.spec.tsx  // integration tests
│       ├── Home.tsx
│       ├── HomeSlice.spec.ts // tests for the slice
│       ├── HomeSlice.ts
│       ├── Item.tsx
│       ├── homeAPI.ts
│       └── types.ts
├── mocks // mock data for the tests
│   └── results.ts
├── setupTests.ts
└── test-utils.jsx // utils for the tests
```

# Testing Reducers

We can start with the functionality of `filtering results`, `add favorites`, and `remove favorites`, as we are using RTK to simplify the creation of reducers and action creators let's create a slice for the HOME entity with this, we will define the structure in our reducer, and add our actions,

```typescript
import { createSlice } from '@reduxjs/toolkit'

export interface HomeState {
  query: string
  results: Results[]
  favorites: number[]
  status: 'idle' | 'loading' | 'failed'
}

const initialState: HomeState = {
  query: '',
  results: [],
  favorites: [],
  status: 'idle',
}

export const homeSlice = createSlice({
  name: 'home',
  initialState,
  reducers: {
    setSearchQuery: (state, action) => {
      state.query = action.payload
    },
    addFavorite: (state, action) => {
      state.favorites.push(action.payload)
    },
    removeFavorite: (state, action) => {
      state.favorites = state.favorites.filter((id) => id !== action.payload)
    },
  },
})

export const { setSearchQuery, addFavorite, removeFavorite } = homeSlice.actions

export default homeSlice.reducer
```

Now let's create our test file as I said early one good advantage of Redux is that our reducers are pure functions and because of that we can easily test them in isolation.

Let's then divide our test into three basic steps:

![testing steps ](/assets/img/group-23.png)

So our test will look like this:

```typescript
import homeReducer, {
  addFavorite,
  HomeState,
  removeFavorite,
  setSearchQuery,
} from './HomeSlice'

describe('Home reducer', () => {
  const state: HomeState = {
    query: '',
    results: [],
    favorites: [],
    status: 'idle',
  }

  it('should handle initial state', () => {
    const initialState: HomeState = state
    const action = { type: 'unknown' }
    const expectedState = initialState

    expect(homeReducer(initialState, action)).toEqual(expectedState)
  })

  it('should handle setSearchQuery', () => {
    const initialState: HomeState = { ...state, query: '' }
    const action = setSearchQuery('test')
    const expectedState: HomeState = { ...state, query: 'test' }

    expect(homeReducer(initialState, action)).toEqual(expectedState)
  })

  it('should add to favorites', () => {
    const initialState: HomeState = { ...state, favorites: [] }
    const action = addFavorite(1)
    const expectedState: HomeState = { ...state, favorites: [1] }

    expect(homeReducer(initialState, action)).toEqual(expectedState)
  })

  it('should remove from favorites', () => {
    const initialState: HomeState = { ...state, favorites: [1] }
    const action = removeFavorite(1)
    const expectedState: HomeState = { ...state, favorites: [] }

    expect(homeReducer(initialState, action)).toEqual(expectedState)
  })
})
```

Now let's check the terminal to see if our tests are passing,
if they are let's move on to the next step.

![Passing Tests](/assets/img/terminalPass.gif 'terminal demo')

# Recap

✨ Perfect ✨

- our tests are working ✅
- our reducer is responding correctly ✅
- all our actions are being handled correctly ✅

so let's recap what we have learned so far:

- when using RTK, we can create reducers and actions very easily
- we can apply the `isolation` approach to organize our tests
- we can use the `functional programming mindset` and test our reducers with following pattern:

### <center> `Initial State => Action => Expected State` </center>



And if you made it this far, my heartfelt thanks 💛
help me by sharing this post and tell me your opinion here,
my goal is to share and learn so don't forget to share and follow me on social media.

How to test reducers in Redux Toolkit with Jest and react-testing-library

Learn with me

Redux Toolkit Testing Async actions

Redux Toolkit Testing Reducers