Idiomatic React Testing Patterns

README.md

Idiomatic React Testing Patterns

Testing React components seems simple at first. Then you need to test something that isn't a pure interaction and things seem to break down. These 4 patterns should help you write readable, flexible tests for the type of component you are testing.

Setup

I recommend doing all setup in the most functional way possible. If you can avoid it, don't set variables in a beforeEach. This will help ensure tests are isolated and make things a bit easier to reason about. I use a pattern that gives great defaults for each test example but allows every example to override props when needed:

const getComponent = (props = {}) => {
	// Any test can override the default props by passing an object to the getComponent function
	props = Object.assign({
		onChange: sinon.spy(),
		title: 'Test Title',
		color: 'red'
	}, props);

	const component = ReactDOM.findDOMNode(TestUtils.renderIntoDocument(
		<MyComponent {...props} />
	));

	return Object.assign(props, { component });
};

// Usage
const { component, onChange } = getComponent();
const { component } = getComponent({ onChange: someFunc });

The Patterns

There are 4 primary patterns that I've identified, have more ideas? Provide examples and rationale in the comments!

Preferred "pure" patterns

• Basic rendering: how props change render results
• Stateless interactions: how interactions change render results or interact with callbacks supplied as props

Impure patterns

Inevitably you will have impure components, these patterns provide consistency in how you test these types of interactions

• Stateful interactions: how interactions change render results relying on this.state or how lifecycle hooks behave
• Instance methods: how the component interacts with external libraries or APIs (very rare)

Disclaimer

You may have a different testing stack and YMMV with how well these patterns work within that environment. For reference, here is the stack we use at Cratejoy and the one I've had the most success with:

• Karma test runner (configured with browserify + babel)
• Mocha test framework
• Chai expect library
• Sinon mock library

test_instance_methods.js

import { expect } from 'chai';
import sinon from 'sinon';

import React from 'react';
import ReactDOM from 'react-dom';
import TestUtils from 'react-addons-test-utils';

import MyComponent from './MyComponent';

/*
* Pattern to be used for testing instance methods of components. These should not be used to test impementation details.
* Examples of good applications of this pattern:
*   - Testing interactions with a stateful DOM API (eg. iframe). NOTE: components should not interact with DOM APIs
*     that are not related to visual display.
*   - Test interactions with an external UI library (eg. an image editor like Aviary)
*/
describe('MyComponent', () => {
	const getComponent = (props = {}) => {
		props = Object.assign({
			onChange: sinon.spy(),
		}, props);

		const node = document.createElement('div');
		// Notice the different rendering method here
		const component = ReactDOM.render(
			<MyComponent {...props} />
		), node);

		return Object.assign(props, { component });
	};

	describe('myMethod', () => {
		it('returns some value', () => {
			const { component } = getComponent();
			expect(component.myMethod()).to.equal('some value');
		});
	});
});

test_render.js

import { expect } from 'chai';
import sinon from 'sinon';

import React from 'react';
import ReactDOM from 'react-dom';
import TestUtils from 'react-addons-test-utils';

import MyComponent from './MyComponent';

/*
* Pattern to be used to assert basic rendering expectations, including how props change the output.
*/
describe('MyComponent', () => {
	const getComponent = (props = {}) => {
	  // Any test can override the default props by passing an object to the getComponent function
		props = Object.assign({
			onChange: sinon.spy(), 
		}, props);

		const component = ReactDOM.findDOMNode(TestUtils.renderIntoDocument(
			<MyComponent {...props} />
		));

		return Object.assign(props, { component });
	};

	it('renders a h1 for title prop', () => {
		const { component } = getComponent({ title: 'My Label' });
		expect(component.querySelector('h1').innerText).to.equal('My Label');
	});
});

test_stateful_interaction.js

import { expect } from 'chai';
import sinon from 'sinon';

import React from 'react';
import ReactDOM from 'react-dom';
import TestUtils from 'react-addons-test-utils';

import MyComponent from './MyComponent';

/*
* To be used when testing a component that is _NOT_ pure (uses this.state) OR when testing lifecycle hooks
* (eg. componentDidUpdate). This is accomplished by re-rendering the the component manually and then asserting
* expectations.
*/
describe('MyComponent', () => {
	const getComponent = (props = {}) => {
		props = Object.assign({
			onChange: sinon.spy(),
		}, props);

		const node = document.createElement('div');
		// Notice the different rendering method here
		const component = ReactDOM.render(
			<MyComponent {...props} />
		), node);

		return Object.assign(props, { component, node });
	};

	context('when clicked', () => {
		it('adds some-class', () => {
			const props = getComponent();

			// Do some action that changes internal state
			TestUtils.Simulate.click(props.component);

			// Re-render (you can also change props here)
			ReactDOM.render(<MyComponent {...props} />, props.node);

			expect(component.className).includes('some-class');
		});
	});
});

test_stateless_interaction.js

import { expect } from 'chai';
import sinon from 'sinon';

import React from 'react';
import ReactDOM from 'react-dom';
import TestUtils from 'react-addons-test-utils';

import MyComponent from './MyComponent';

/*
* Pattern to be used to assert pure interaction expectations that do not require any lifecycle hooks or internal state.
*/
describe('MyComponent', () => {
	const getComponent = (props = {}) => {
		props = Object.assign({
			onChange: sinon.spy(), 
		}, props);

		const component = ReactDOM.findDOMNode(TestUtils.renderIntoDocument(
			<MyComponent {...props} />
		));

		return Object.assign(props, { component });
	};

	context('when the component is changed', () => {
		it('calls onChange', () => {
			const { component, onChange } = getComponent();
			const inputNode = input.querySelector('input[type=text]');
			TestUtils.Simulate.change(inputNode, { target: { value: 'new' } });
			expect(onChange.calledWith('new')).to.be.true;
		});
	});
});

@evandrix +1

@evandrix @josephmisiti @venkat-gan I haven't personally used Jest or seen a great reason to. We have found that using spies for any props that are functions is the most mocking we need. If you have services or model interactions inside your components, I highly recommend switching to the Flux or Redux pattern which simplifies these interactions tremendously.

Excellent work @joshdover

🎉 I would have loved to find this some months ago, I had to learn this the hard way.