Testing ⚛️ components using render props

With the release of my
Advanced React Component Patterns
course on egghead.io, a lot of people have been asking me
about render props. Specifically with regards to testing. Maybe eventually I’ll
create a course on egghead.io about testing react
components. Until then, I’ve decided to write this about some approaches that
could help you when testing a component that renders a render prop component 🙂

Note: This isn’t about how to test components that implement the render prop
pattern.
Rather, this is about how to tests components that_ use _components that
implement the render prop pattern 🙂

In preparing this blog post, I created
this repo which
totally works and you can give it a look if you want more details 🙂 In that
repo, we have a component called FruitAutocomplete which is (basically)
implemented like so:

import * as React from 'react'
import {render} from 'react-dom'
import Downshift from 'downshift'

const items = ['apple', 'pear', 'orange', 'grape', 'banana']

function FruitAutocomplete({onChange}) {
  return (
    <Downshift
      onChange={onChange}
      render={({
        getInputProps,
        getItemProps,
        getLabelProps,
        isOpen,
        inputValue,
        highlightedIndex,
        selectedItem,
      }) => (
        <div>
          <label {...getLabelProps()}>Enter a fruit</label>
          <input {...getInputProps()} />
          {isOpen ? (
            <div data-test="menu">
              {items
                .filter(i => !inputValue || i.includes(inputValue))
                .map((item, index) => (
                  <div
                    {...getItemProps({
                      key: item,
                      'data-test': `item-${item}`,
                      index,
                      item,
                      style: {
                        backgroundColor:
                          highlightedIndex === index ? 'lightgray' : 'white',
                        fontWeight: selectedItem === item ? 'bold' : 'normal',
                      },
                    })}
                  >
                    {item}
                  </div>
                ))}
            </div>
          ) : null}
        </div>
      )}
    />
  )
}

export default FruitAutocomplete

End to End tests

First off, I should say that render props are really just an implementation
detail. So if you’re writing E2E tests (with something like the amazing
Cypress.io), then you shouldn’t have to test anything any
differently whether you’re using render props or anything else. You just
interact with the component the way the user would (type in the input, select an
item, etc.). That may be obvious, but I think that brings up a pretty important
point. The higher you’re up on the
“testing pyramid,” the less
implementation details matter, as you go down the pyramid, you have to deal with
implementation details a little more.

Integration Tests

That said, I suggest focusing on integration tests. With an
integration test, you likewise don’t have to change too much about how you test
the component. Here are the integration tests from the repo. You’ll notice that
there’s no indication that the FruitAutocomplete component is implemented with
a render prop component (an implementation detail):

import * as React from 'react'
import {mount} from 'enzyme'
import FruitAutocomplete from '../fruit-autocomplete'

// some handy utilities
// learn more about this `sel` function
// from my other blog post: http://kcd.im/sel-util
const sel = id => `[data-test="${id}"]`
const hasMenu = wrapper => wrapper.find(sel('menu')).length === 1

test('menu is closed by default', () => {
  const wrapper = mount(<FruitAutocomplete />)
  expect(hasMenu(wrapper)).toBe(false)
})

test('lists fruit with a keydown of ArrowDown on the input', () => {
  const wrapper = mount(<FruitAutocomplete />)
  const input = wrapper.find('input')
  input.simulate('keydown', {key: 'ArrowDown'})
  expect(hasMenu(wrapper)).toBe(true)
})

test('can search for and select "banana"', () => {
  const onChange = jest.fn()
  const wrapper = mount(<FruitAutocomplete onChange={onChange} />)
  const input = wrapper.find('input')
  input.simulate('change', {target: {value: 'banana'}})
  input.simulate('keydown', {key: 'ArrowDown'})
  input.simulate('keydown', {key: 'Enter'})
  expect(onChange).toHaveBeenCalledTimes(1)
  const downshift = expect.any(Object)
  expect(onChange).toHaveBeenCalledWith('banana', downshift)
  expect(input.instance().value).toBe('banana')
})

So how do you test a component that uses a render prop component? Whelp, if
you’re using E2E or Integration tests, you pretty much don’t need to do anything
different! Just mount your component and interact with it the way you would
normally. One thing I should note is that downshift itself is a very
well-tested component, so you shouldn’t have to test interactions that it
provides out of the box. Just focus on what your component is doing. And that’s
what I’d suggest: test your render prop component really well, then do some
high-level tests for the users of the component.

Unit tests

Things get a little tricky with unit tests. If you don’t want to include
downshift in your tests, then you have to get access to the function you’re
passing to the render prop. There are a few ways to do this.

The first and most obvious way to do this is to extract the renderprop
function and export that:

function FruitAutocomplete({onChange}) {
  return <Downshift onChange={onChange} render={fruitAutocompleteRender} />
}

// NOTE: this is _not_ technically component, it's _like_ a function component
// but it's not rendered with React.createElement, so it's simply
// a function that returns JSX.
function fruitAutocompleteRender(arg) {
  return <div>{/* what you render */}</div>
}

export {fruitAutocompleteRender}
export default FruitAutocomplete

And now you can import that function directly into your test and use it to
render JSX like so:

import * as React from 'react'
import {render} from 'enzyme'

const downshiftStub = {
  isOpen: false,
  getLabelProps: p => p,
  getInputProps: p => p,
  getItemProps: p => p,
}

const sel = id => `[data-test="${id}"]`
const hasMenu = wrapper => wrapper.find(sel('menu')).length === 1
const hasItem = (wrapper, item) =>
  wrapper.find(sel(`item-${item}`)).length === 1
const renderFruitAutocompleteRenderer = props =>
  render(fruitAutocompleteRender({...downshiftStub, ...props}))

test('shows no menu when isOpen is false', () => {
  const wrapper = renderFruitAutocompleteRenderer({isOpen: false})
  expect(hasMenu(wrapper)).toBe(false)
})

test('shows the menu when isOpen is true', () => {
  const wrapper = renderFruitAutocompleteRenderer({isOpen: true})
  expect(hasMenu(wrapper)).toBe(true)
})

test('when the inputValue is banana, it shows banana', () => {
  const wrapper = renderFruitAutocompleteRenderer({
    isOpen: true,
    inputValue: 'banana',
  })
  expect(hasItem(wrapper, 'banana')).toBe(true)
})

So this works fine. A few things to note:

• Doing this requires a little less code and is markedly simpler
• We have to stub out what things downshift passes to us
• We have to extract the render prop to a separate function and export it

Those second points bother me a fair amount. There’s another way to get at the
render prop without extracting and exporting it though. Here’s that last test
implemented as if we didn’t export the render prop function:

import * as React from 'react'
import {mount, render} from 'enzyme'
import Downshift from 'downshift'
import FruitAutocomplete from '../fruit-autocomplete'

const downshiftStub = {
  isOpen: false,
  getLabelProps: p => p,
  getInputProps: p => p,
  getItemProps: p => p,
}

test('when the inputValue is banana, it shows banana', () => {
  const fruitAutocompleteRender = mount(<FruitAutocomplete />)
    .find(Downshift)
    .prop('render')
  const wrapper = render(
    fruitAutocompleteRender({
      ...downshiftStub,
      isOpen: true,
      inputValue: 'banana',
    }),
  )
  expect(hasItem(wrapper, 'banana')).toBe(true)
})

I also don’t really like this because I don’t like saying: “Hey,
FruitAutocomplete, I know that you use Downshift and that Downshift uses a prop
called render.” And to me that’s diving even further into implementation
details.

Also, this still doesn’t address my concern of stubbing out downshift. Read
more about how I feel about this in this blog post.

There’s actually another way we could do this and that would be to use
jest.mock to mock the downshift module. But I’m not going to create an
example of that because it’s no better 🙂

Conclusion

So I suggest that you just stick with an integration test here and don’t bother
trying to unit test your render function. I think you’ll have more confidence
that things wont break if you do.

I should note also that for some components that require a provider to exist
(like react-redux or React Router), that you simply render your component
within a provider. I have
some examples
of doing this in my
testing workshop for frontend masters.

I hope this is helpful to you! Good luck!