Tag Archive

Tag Archives for " redux "

Test Clicks On Connected Components In Under 10 Lines of Code

Here’s a fairly benign component, that can give developers pause when its time to write unit tests for your components: 

const ClickableButton = props => (
  <button onClick={props.doSomething}>Click Me!</button>
)

const mapDispatchToProps () => ({
  doSomething: dispatch(someFancyAction())
})

export default connect(
  null, 
  mapDispatchToProps,
)(ClickableButton)

There is only thing worth testing here: That when we click the button, the function we passed in as a prop gets called. That prop function could be a complex chain of actions & API calls. You don’t want to stress about that, at least not in these tests.  But to do this, are we going to have to create mock store and a provider component just because it’s connected? Ugh!

There has to be a better way. 

You Can Remove The Redux Connection Entirely

While you want your component to be the default export, you can export the unconnected component, and just test that! Hat tip to Dave Ceddia for show me a better way to export a connected component.  All you have to do is change one line: 

export const ClickableButton = props => (

As an additional trick, if you have any helper functions not attached to the component, you can export those as well for easy testing. 

With Jest and Enzyme, The Rest is Easy

Inside our test, import the unconnected component. Then, you can create a mock function using Jest, and simulate the click using Enzyme. Here’s what the test looks like all together: 

describe('<ClickableButton />', () => {
  it('calls the doThing prop when the button is clicked', () => {
    const props = { doSomething: jest.fn() }
    const wrapper = shallow(<ClickableButton {...props} />)
    wrapper.find("button").first().simulate("click")
    expect(props.doSomething).toHaveBeenCalled()
  })
})

Write Redux Reducer Tests Fast

Redux may come with a lot of boilerplate, patterns, and libraries, but at its core it’s simple.  A current state and an action go in, new state comes out.

Just because the code is simple doesn’t mean it shouldn’t be tested. If you are using Redux in your application, that means your store is a core part of it. For that reason, you should have tests for every action your reducer could take, and every logic branch that they could take. But don’t fret! Since reducers aren’t complicated, neither is writing tests. With a little setup, you can follow this pattern and knock out reducer tests like a pro. 

Setting Up For Reducer Tests

The only setup I use is to use the startState object if I need to have an initials state for every test. Unlike testing thunks, no mock stores necessary. Our initial state (and states we use in testing) will be plain objects. These tests should taste like vanilla.

const startState = {} // initial state shape if needed

The Reducer We’ll Be Testing

I’ll pull the reducer example from an earlier tutorial about creating asynchronous actions. Code reuse, woohoo! 🎉

const postReducer = (state = {}, action) => {
  switch (action.type) {
    case types.LOAD_POST_REQUEST:
      return {
        ...state,
        posts_loading: true,
      }
      case types.LOAD_POST_SUCCESS:
        return {
          ...state,
          posts_loading: false,
          posts: action.payload,
        }
        case types.LOAD_POST_FAILURE:
        return {
          ...state,
          posts_loading: false,
          posts_error: action.payload,
        }
        //...other actions
        default:
           return state 
        }
    }
}

And for quick reference, here are the action creators you can use to work with this reducer. We’ll need them shortly: 

const loadPostsRequest = () => ({ type: types.LOAD_POSTS_REQUEST })

const loadPostsSuccess = posts => ({
  type: types.LOAD_POSTS_SUCCESS,
  payload: posts,
})

const loadPostsFailure = error => ({
  type: types.LOAD_POSTS_FAILURE,
  payload: error,
  error: true,
})

export default {
  loadPostsRequest,
  loadPostsSuccess,
  loadPostsFailure,
}

The Reducer Test Pattern

Every test I write for a reducer follows this pattern: 

  1. I declare an initial state
  2. I declare an expected result state
  3. I create an action
  4. I call the reducer with the action and the initial state
  5. I compare the actual and expected state where I expect changes. 

Here’s the template, in code form: 

it('should apply the updates as expected', () => {
  const start = { ...startState } // add or change fields as needed.
  const expected = {} // expected result state
  const action = actions.myActionCreator() //include arguments as needed
  const actual = reducer(start, action) 
  expect(actual).toEqual(expected)
})

Boom. done.  To keep things even simpler, if your application doesn’t have an initial state, you can declare start from scratch. As you’ll see below, you will want to tweak the formula for specific cases, but they will all follow this template. 

Example 1: LOAD_POSTS_REQUEST

Let’s see it in action.  All our first action is responsible for is toggling a boolean value. Notice in this example, I’m not going to create an expected result state. Since we are only interested in one boolean, we can look at that value, and use Jest’s toBeTruthy() and toBeFalsy() matchers. If you’re not familiar with all of the matchers, here’s a quick list for reference. 

describe('LOAD_POSTS_REQUEST', () => {
  it('marks the current task as not loaded', () => {
    const start = {
        ...startState,
        posts_loading: false,
      }
    const action = actions.loadPostsRequest()
    const actual = reducer(start, action).posts_loading
    expect(actual).toBeTruthy()
  })
})

Example 2: LOAD_POSTS_SUCCESS

Here we’ll want to write two tests: one to confirm we load the posts into state, and one to confirm we have marked that the posts are no longer in a loading state.  Because of this, we can move some of our setup code into a before function.

describe('LOAD_POSTS_SUCCESS', () => {
  let actual
  let expected
  beforeEach(() => {
    const start = {
      ...startState,
      posts: [],
      posts_loading: true
    }
    expected = ['some', 'posts']
    const action = actions.loadPostsSuccess(expected)
    actual = reducer(start, action)
  })

  it('marks posts as loaded', () => {
    expect(actual.posts_loading).toBeFalsy()
  })
  it('saves posts in state', () => {
    expect(actual.posts).toEqual(expected)
  })
})

Example 3: LOAD_POSTS_FAILURE

Similar to our thunk example, our failure use case looks similar to our success case. Still, it’s good to be thorough. Few things are as frustrating as expecting a useful error message and instead finding nothing. 

describe('LOAD_POSTS_FAILURE', () => {
  let actual
  let expected
  beforeEach(() => {
    const start = {
      ...startState,
      posts_error: null,
      posts_loading: true
    }
    expected = 'Posts not found!'
    const action = actions.loadPostsFailure(expected)
    actual = reducer(start, action)
  })

  it('marks posts as loaded', () => {
    expect(actual.posts_loading).toBeFalsy()
  })
  it('saves posts error in state', () => {
    expect(actual.posts_error).toEqual(expected)
  })
})

Apply This To Your Codebase

If there are errors in how your reducer updates state, it can be difficult to debug. While the Redux DevTools help, wouldn’t it be better if those bugs never even made it to the browser? To help prevent them from escaping, make sure your reducers are thoroughly tested. The pattern can easily adjust to other common reducer use cases: 

  • Have conditional logic in your reducer? Write a test for each logic branch. 
  • Have validation in your reducer? Throw valid and invalid actions at it, to make sure it handles both cases properly. 
  • Transforming data within your reducer? Adjust the expected call to ensure the data comes out shaped just how you want. 

Still have a particular action that you are having a difficult time with? It could be a sign that you have a messy or overly complex action or state shape, and some refactoring may be in order. 

How to Test Async Redux Thunks

In a previous post, you learned how to make HTTP requests inside your redux application. We use redux-thunk, a library that enables you to dispatch functions in addition to flux-style actions. With it, you can dispatch functions to handle more complex cases such as asynchronous operations. But then how do you test them? Testing can be more work than writing the functioning code itself. Dealing with server responses and timing was hard enough as it is. Luckily, there are tools and patterns you can apply to work, and make your codebase more reliable with ease.

First, we’ll take a look at the tools that we will be using for testing. Then, how to apply them to our operation. 

Tools of the Testing Trade

  • Jest – Jest is a JavaScript testing library from the Facebook development ecosystem, just like React. It’s designed to require no configuration and get out of your way you write tests easier and faster. 
  • Redux-mock-store – Since the primary goal of the action is to update a redux store, you will need a way to mock the redux store. redux-mock-store does just that.
  • Moxios – Moxios is a Javascript library that stubs out Axios requests. We’ll use this to decouple our code from the server so we can isolate our logic and test only

Quick Review: Our HTTP Action

Here’s the thunk from the previous tutorial: 

const fetchPosts = () => {
  const url = '/our-app/posts.json'
  return (dispatch) => {
    dispatch(actions.loadPostsRequest())
    axios.get(url)
      .then((response) => {
        dispatch(actions.loadPostsSuccess(response.data))
      })
      .catch((error) => {
        dispatch(actions.loadTaskHistoryFailure(error))
      })
  }
}

Now, let’s get to work on adding some tests to this code, so that we can make changes to code base without fear of causing a regression.

1. Create a Mock Store

First, we’ll set up our store. Since our redux application uses the thunk middleware, we’ll also need to apply that middleware when testing. Once we’ve done that we’ll create a function to help us set up our state for tests. Many applications have some kind of an initial state. Instead of creating that for every test, instead, we’ll create a helper function that takes a configured store, and combines the initial state with the state you pass as an argument.

import thunk from 'redux-thunk'
import configureMockStore from 'redux-mock-store'

export const startState = {} //put initial state here

export const mockStore = configureMockStore([thunk])

export const makeMockStore = (state = {}) => { 
  return mockStore({
    ...startState,
    ...state,
  })
}

2. Create Some Moxios Helpers

Next, let’s create a couple of helper functions for moxios. Axios & Moxios look at the status code to determine whether or not to resolve or reject the promise. These two functions will save us a bit of time when writing multiple API tests. These helper functions will save you quite a few keystrokes if your application has a lot of different HTTP-based thunks.

const mockSuccess = data => ({ status: 200, response: { data } })
const mockError = error => ({ status: 500, response: error })

3. Configure Setup and Teardown for Your Tests

For our tests, we’ll need to set up and tear down the Moxios adapter. It intercepts outgoing HTTP requests, allowing you to control the response the function you are testing gets back.  Here’s what that looks like: 

describe('fetchPosts', () => {
  beforeEach(() => moxios.install())
  afterEach(() => moxios.uninstall())
})

4. Write Your On Success Test

What do we want to assert here?

You aren’t testing any of the server-side logic. You aren’t testing that state changed because that’s the reducer’s job. You should write separate reducer tests for that. The thunk is only responsible for deciding which actions to dispatch, so that’s what to focus on.

So the jobs our test needs to accomplish are:

  1. create a mock instance of the store. You’ll be dispatching actions to it. 
  2. create a mock server response. 
  3. call your thunk, and assert that it dispatched the correct actions to your mock store.

Altogether, it looks like this. 

  it('dispatches loadPostsSuccess with server data on success', () => {
    const response = ['some', 'posts']
    const store = makeMockStore()
    moxios.wait(() => {
      const request = moxios.requests.mostRecent()
      request.respondWith(mockSuccess(response))
    })

    const expected = [
      actions.loadPostsRequest(),
      actions.loadPostsSuccess(response),
    ]

    store.dispatch(fetchPosts()).then(() => {
      const actual = store.getActions()
      expect(actual).toEqual(expected)
    })
  })

5. Now do the Same for the Error Response

Don’t just test the happy path. When writing tests it’s prudent to ask yourself, “what could go wrong?” Our server could throw an error response, so we want to test for that use case as well. In our example, the error test case looks almost identical to our success test case. 

  it('dispatches loadPostsError with server data on success', () => {
    const response = 'error message'
    const store = makeMockStore()
    moxios.wait(() => {
      const request = moxios.requests.mostRecent()
      request.respondWith(mockError(response))
    })

    const expected = [
      actions.loadPostsRequest(),
      actions.loadPostsError(response),
    ]

    store.dispatch(fetchPosts()).then(() => {
      const actual = store.getActions()
      expect(actual).toEqual(expected)
    })
  })

Apply This To Your Applications

This is the purest example of how to test asynchronous operations in your application. Of course in the real world, it’s never quite that simple. If there are additional use cases that you can think of, be sure to write tests for those as well. For example, are there different kinds of successful or error responses you could expect from the server? Do you need additional logic to handle them? If so, it could be a use case for creating additional tests. 

Think through your different use cases and decide the best approach.

How to Perform HTTP Requests with React & Redux

Async is one of the toughest problems in front-end development. It’s one of the reasons Redux and React were created. React all started when Facebook had what seemed like a trivial problem: Sometimes, the “unread messages” count in the header and the footer of the page would be different. This Skinner box is so important to Facebook’s business model, they decided to build a whole framework around it. By managing all changes in a global state, and rendering components based off of that state exclusively, you eliminate these kinds of problems. 

Most Async requests come from talking back and forth with the server. Let’s look at how we can make updates to our Redux state with HTTP requests.

First, Installing the Middleware.

Redux doesn’t come with a way to handle this out of the box.  The typical model in Redux is that you call the dispatch function, passing in an action as an argument. The dispatch function gives that action to the reducer, which goes up to update the state. All of these are synchronous actions. What if we want to dispatch asynchronous actions? For that, we’ll be using middleware called “redux-thunk.” redux-thunk gives you the ability to dispatch functions or actions. These functions can then dispatch actions themselves, but more on that later. First, install the middleware:

import { createStore, applyMiddleware } from 'redux'
import thunk from 'redux-thunk'

const initial state = {
  posts_loading: false,
  posts: [],
  posts_error: null,
}

const configureStore = () => createStore(
  reducer,
  initialState,
  applyMiddleware(thunk)),
)

export default configureStore

 A Couple Quick Thunk Examples

A thunk is a special kind of action creator that returns a function. The function receives two arguments: dispatch and getState, which unsurprisingly is a function that returns the state. That’s another benefit of using thunk: it allows us to fire dispatches based on the current state, without passing in any arguments. Here are some examples:

const slowDispatch = () => {
  return (dispatch, getState) => {
     return setTimeout(() =>
       dispatch(increment()), 1000)
     )
  )
}

const maybeDispatch = () => {
  return (dispatch, getState) => {
    if (getState().allowIncrement) dispatch(increment())
  }
}

// If you want to be terser, you can write these as one-liners

const slowDispatch = () => (dispatch) => setTimeout(() => dispatch(increment()),1000)

const maybeDispatch = () => (dispatch, getState) => getState().allowIncrement ? dispatch(increment()) : null

Create the actions & action creators.

aka good old Redux boilerplate. We’ll be following the ducks pattern for this exercise.

First, there are three actions, one that will tell us when the request started, one for handling success, and one for handling errors. We’ll create types for these. You could just use the strings instead of declaring constants, but this strategy helps you more quickly identify typos when debugging. A mistyped action will throw an error instead of failing silently.

// types.js
const LOAD_POSTS_REQUEST = 'tasks/history/request'
const LOAD_POSTS_SUCCESS = 'tasks/history/success'
const LOAD_POSTS_FAILURE = 'tasks/history/failure'

export default { 
  LOAD_POSTS_REQUEST,
  LOAD_POSTS_SUCCESS,
  LOAD_POSTS_FAILURE,
}

Then, we’ll create our action creators. Again, we could do this inside of our thunk, but this helps keep the code clean. You can also use these when writing tests, and they will help you write them more efficiently.  We’ll create three: one to update the state when we are loading, one when we get a successful response, and one when we get an error.

import types from './types'

const loadPostsRequest = () => ({ type: types.LOAD_POSTS_REQUEST })

const loadPostsSuccess = posts => ({
  type: types.LOAD_POSTS_SUCCESS,
  payload: posts,
})

const loadPostsFailure = error => ({
  type: types.LOAD_POSTS_FAILURE,
  payload: error,
  error: true,
})

export default {
  loadPostsRequest,
  loadPostsSuccess,
  loadPostsFailure,
}

Updating Our Reducer

Now that we have actions, we need to handle them in our reducer. We’ll store three variables. First, a boolean to track the loading state. We can use this to toggle loading indicators in our interface. We’ll also store the results in an array, and store the error we get in response if there is a problem.

port types from './types'

const postReducer = (state = {}, action) => {
  switch (action.type) {
    case types.LOAD_POST_REQUEST:
      return {
        ...state,
        posts_loading: true,
      }
      case types.LOAD_POST_SUCCESS:
        return {
          ...state,
          posts_loading: false,
          posts: action.payload,
        }
        case types.LOAD_POST_FAILURE:
        return {
          ...state,
          posts_loading: false,
          posts_error: action.payload,
        }
        //...other actions
        default:
           return state 
        }
    }
}

Who Will Dispatch the Dispatches? Creating Our Thunk

In the ducks pattern, operations are higher-order action creators. Thunks are one category of operation. Another way to think of an operation is an action creator+. It will dispatch actions, sometimes more than one, and sometimes take care of other business logic. Again what makes thunks specific is that return a function instead of an action. 

In our operations, we’ll be deploying some combination of the three actions we defined earlier. We’ll be using Axios to make our HTTP request.

const fetchPosts = () => {
  const url = '/our-app/posts.json'
  return (dispatch) => {
    dispatch(actions.loadPostsRequest())
    axios.get(url)
      .then((response) => {
        dispatch(actions.loadPostsSuccess(response.data))
      })
      .catch((error) => {
        dispatch(actions.loadTaskHistoryFailure(error))
      })
  }
}

And there you have it! Now that you’ve written your thunk, you want to make sure it’s well tested and resilient to change. In the next article, you’ll learn exactly how to test redux thunks.