This site runs best with JavaScript enabled.

Test Isolation with React

July 02, 2018

Video Blogger

Photo by Mika Matin on Unsplash


Why your tests should be completely isolated from one another and how to do that.

Read to the end, I've got some cool things in the "things not to miss" section

The inspiration for this newsletter comes from seeing React tests that look like this:

1const utils = render(<Foo />)
2
3test('test 1', () => {
4 // use utils here
5})
6
7test('test 2', () => {
8 // use utils here too
9})

So I want to talk about the importance of test isolation and guide you to a better way to write your tests to improve the reliability of the tests, simplify the code, and increase the confidence your tests and provide as well.

Let's take this simple component as an example:

1import React from 'react'
2
3class Counter extends React.Component {
4 static defaultProps = {
5 initialCount: 0,
6 maxClicks: 3,
7 }
8 initialState = {count: this.props.initialCount}
9 state = this.initialState
10 handleReset = () => this.setState(this.initialState)
11 handleClick = () =>
12 this.setState(({count}) =>
13 this.clicksAreTooMany(count) ? null : {count: count + 1},
14 )
15 clicksAreTooMany(count) {
16 return count >= this.props.maxClicks
17 }
18 render() {
19 const {count} = this.state
20 const tooMany = this.clicksAreTooMany(count)
21 return (
22 <div>
23 <button onClick={this.handleClick} disabled={tooMany}>
24 Count: {count}
25 </button>
26 {tooMany ? <button onClick={this.handleReset}>reset</button> : null}
27 </div>
28 )
29 }
30}
31
32export {Counter}

Here's a rendered version of the component:

a rendered version of the component

Our first test suite

Let's start with a test suite like the one that inspired this newsletter:

1import 'jest-dom/extend-expect' // gives us the toHaveTextContent/toHaveAttribute matchers
2import React from 'react'
3import {renderIntoDocument, cleanup, fireEvent} from 'react-testing-library'
4import {Counter} from '../counter'
5
6const {getByText} = renderIntoDocument(
7 <Counter maxClicks={4} initialCount={3} />,
8)
9const counterButton = getByText(/^count/i)
10
11afterAll(cleanup) // when all tests are finished, unmount the component
12
13test('the counter is initialized to the initialCount', () => {
14 expect(counterButton).toHaveTextContent(/3/)
15})
16
17test('when clicked, the counter increments the click', () => {
18 fireEvent.click(counterButton)
19 expect(counterButton).toHaveTextContent(/4/)
20})
21
22test(`the counter button is disabled when it's hit the maxClicks`, () => {
23 fireEvent.click(counterButton)
24 expect(counterButton).toHaveAttribute('disabled')
25})
26
27test(`the counter button does not increment the count when clicked when it's hit the maxClicks`, () => {
28 expect(counterButton).toHaveTextContent(/4/)
29})
30
31test(`the reset button has been rendered and resets the count when it's hit the maxClicks`, () => {
32 fireEvent.click(getByText(/reset/i))
33 expect(counterButton).toHaveTextContent(/3/)
34})

These tests give us 100% coverage of the component and verify exactly what they say they'll verify. The problem is that they share mutable state. What is the mutable state they're sharing? The component! One test clicks the counter button and the other tests rely on that fact to pass. If we were to delete (or .skip) the test called "when clicked, the counter increments the click" it would break all the following tests:

broken tests

This is a problem because it means that we can't reliably refactor these tests, or run a single test in isolation of the others for debugging purposes because we don't know which tests are impacting the functionality of others. It can be really confusing when someone comes in to make changes to one test and other tests start breaking out of nowhere.

Better

So let's try something else and see how that changes things:

1import 'jest-dom/extend-expect'
2import React from 'react'
3import {renderIntoDocument, cleanup, fireEvent} from 'react-testing-library'
4import {Counter} from '../counter'
5
6let getByText, counterButton
7
8beforeEach(() => {
9 const utils = renderIntoDocument(<Counter maxClicks={4} initialCount={3} />)
10 getByText = utils.getByText
11 counterButton = utils.getByText(/^count/i)
12})
13
14afterEach(cleanup)
15
16test('the counter is initialized to the initialCount', () => {
17 expect(counterButton).toHaveTextContent(/3/)
18})
19
20test('when clicked, the counter increments the click', () => {
21 fireEvent.click(counterButton)
22 expect(counterButton).toHaveTextContent(/4/)
23})
24
25test(`the counter button is disabled when it's hit the maxClicks`, () => {
26 fireEvent.click(counterButton)
27 expect(counterButton).toHaveAttribute('disabled')
28})
29
30test(`the counter button does not increment the count when clicked when it's hit the maxClicks`, () => {
31 fireEvent.click(counterButton)
32 fireEvent.click(counterButton)
33 expect(counterButton).toHaveTextContent(/4/)
34})
35
36test(`the reset button has been rendered and resets the count when it's hit the maxClicks`, () => {
37 fireEvent.click(counterButton)
38 fireEvent.click(getByText(/reset/i))
39 expect(counterButton).toHaveTextContent(/3/)
40})

With this, each test is completely isolated from the other. We can delete or skip any test and the rest of the tests continue to pass. The biggest fundamental difference here is that each test has its own count instance to work with and it's unmounted after each test (afterEach(cleanup)). This significantly reduces the amount of complexity of our tests with minor changes.

One thing people often say against this approach is that it's slower than the previous approach. I'm not totally sure how to respond to that... Like, how much slower? Like a few milliseconds? In that case, so what? A few seconds? Then your component should probably be optimized because that's just terrible. I know it adds up over time, but with the added confidence and improved maintainability of this approach, I'd gladly wait an extra few seconds to render things this way. In addition, you shouldn't often have to run the entire test base anyway thanks to great watch mode support like we have in Jest.

Even better

So I'm actually still not super happy with the tests we have above. I'm not a huge fan of beforeEach and sharing variables between tests. I feel like they lead to tests that are harder to understand. Let's try again:

1import 'jest-dom/extend-expect'
2import React from 'react'
3import {renderIntoDocument, cleanup, fireEvent} from 'react-testing-library'
4import {Counter} from '../counter'
5
6afterEach(cleanup)
7
8function renderCounter(props) {
9 const utils = renderIntoDocument(
10 <Counter maxClicks={4} initialCount={3} {...props} />,
11 )
12 const counterButton = utils.getByText(/^count/i)
13 return {...utils, counterButton}
14}
15
16test('the counter is initialized to the initialCount', () => {
17 const {counterButton} = renderCounter()
18 expect(counterButton).toHaveTextContent(/3/)
19})
20
21test('when clicked, the counter increments the click', () => {
22 const {counterButton} = renderCounter()
23 fireEvent.click(counterButton)
24 expect(counterButton).toHaveTextContent(/4/)
25})
26
27test(`the counter button is disabled when it's hit the maxClicks`, () => {
28 const {counterButton} = renderCounter({
29 maxClicks: 4,
30 initialCount: 4,
31 })
32 expect(counterButton).toHaveAttribute('disabled')
33})
34
35test(`the counter button does not increment the count when clicked when it's hit the maxClicks`, () => {
36 const {counterButton} = renderCounter({
37 maxClicks: 4,
38 initialCount: 4,
39 })
40 fireEvent.click(counterButton)
41 expect(counterButton).toHaveTextContent(/4/)
42})
43
44test(`the reset button has been rendered and resets the count when it's hit the maxClicks`, () => {
45 const {getByText, counterButton} = renderCounter()
46 fireEvent.click(counterButton)
47 fireEvent.click(getByText(/reset/i))
48 expect(counterButton).toHaveTextContent(/3/)
49})

Here we've increased some boilerplate, but now every test is not only isolated technically, but also visually. You can look at a test and see exactly what it does without having to worry about what hooks are happening within the test. This is a big win in the ability for you to be able to refactor, remove, or add to the tests.

Even better better

I like what we have now, but I think we need to take things one step further before I feel really happy about things. We've split our tests up by functionality, but what we really want to have confidence in is the use case that our component satisfies. It allows clicks until the maxClicks is reached, then requires a reset. That's what we're trying to verify and gain confidence in. I'm much more interested in use cases when I'm testing than specific functionality. So what would these tests look like if we concerned ourselves more with the use case than the individual functionality?

1import 'jest-dom/extend-expect'
2import React from 'react'
3import {renderIntoDocument, cleanup, fireEvent} from 'react-testing-library'
4import {Counter} from '../counter'
5
6afterEach(cleanup)
7
8test('allows clicks until the maxClicks is reached, then requires a reset', () => {
9 const {getByText} = renderIntoDocument(
10 <Counter maxClicks={4} initialCount={3} />,
11 )
12 const counterButton = getByText(/^count/i)
13
14 // the counter is initialized to the initialCount
15 expect(counterButton).toHaveTextContent(/3/)
16
17 // when clicked, the counter increments the click
18 fireEvent.click(counterButton)
19 expect(counterButton).toHaveTextContent(/4/)
20
21 // the counter button is disabled when it's hit the maxClicks
22 expect(counterButton).toHaveAttribute('disabled')
23 // the counter button no longer increments the count when clicked.
24 fireEvent.click(counterButton)
25 expect(counterButton).toHaveTextContent(/4/)
26
27 // the reset button has been rendered and is clickable
28 fireEvent.click(getByText(/reset/i))
29
30 // the counter is reset to the initialCount
31 expect(counterButton).toHaveTextContent(/3/)
32
33 // the counter can be clicked and increment the count again
34 fireEvent.click(counterButton)
35 expect(counterButton).toHaveTextContent(/4/)
36})

I really love this kind of test. It helps me avoid thinking about functionality and focus more on what I'm trying to accomplish with the component. It serves as much better documentation of the component than the other tests as well.

In the past, the reason we wouldn't do this (have multiple assertions in a single test) is because it was hard to tell which part of the test broke. But now we have much better error output and it's really easy to identify what part of the test broke. For example:

broken tests

The code frame is especially helpful. It shows not only the line number, but the code around the failed assertion which shows our comments and other code to really help give us context around the error message that not even our previous tests gave us.

I should mention, this isn't to say that you shouldn't separate test cases for a component! There are many reasons you'd want to do that and most of the time you will. Just focus more on use cases than functionality and you'll generally cover most of the code you care about with that. Then you can have a few extra tests to handle edge cases.

Conclusion

I hope this is helpful to you! You can find the code for this example here. Try to keep your tests isolated from one another and focus on use cases rather than functionality and you'll have a much better time testing! Good luck!

Learn more about testing from me:

Things to not miss:

Discuss on TwitterEdit post on GitHub

Share article
loading relevant upcoming workshops...

TestingJavaScript.com

Your essential guide to flawless testing.

Jump on this self-paced workshop and learn the smart, efficient way to test any JavaScript application. 🏆

Start Now
Kent C. Dodds

Kent C. Dodds is a JavaScript software engineer and teacher. He's taught hundreds of thousands of people how to make the world a better place with quality software development tools and practices. He lives with his wife and four kids in Utah.