---
id: test-utils
title: Test Utilities
permalink: docs/test-utils.html
layout: docs
category: Reference
---
**Importing**
```javascript
All doc updates forv15.5 (#9359)
* `react-addons-test-utils` -> `react-dom/test-utils`
Updating all references and docs on the `React.addons.TestUtils` and the
shallow renderer to refer to the correct targets.
Instead of:
```
const React = require('react');
// ...
React.addons.Testutils
// or
const ReactTestUtils = require('react-addons-test-utils');
```
we now show:
```
const ReactTestUtils = require('react-dom/test-utils');
```
And for shallow renderer, instead of:
```
const shallowRenderer = TestUtils.createRenderer();
```
we now show:
```
const shallowRenderer = require('react-test-renderer/shallow');
```
* Update the 'prev' and 'next' attributes of 'add-ons' docs
These flags are used to set arrow links to easily navigate through the
documents. They were wrong or missing in some of the 'add-ons' pages and
this bothered me when manually testing the updates from the previous
commit.
* Update syntax for instantiating shallow renderer
Missed this when updating the docs for the changes to shallow-renderer
in React 15.5.
* Fix pointers in addons docs
Thanks @bvaughn for catching this
* Make example of shallow renderer more consistent
We should show using the same variable names between code samples.
* Make names in example even more consistent
We should use the same variable name for the same thing across examples.
`renderer` -> `shallowRenderer`.
* Update docs to deprecate React<CSS>TransitionGroup
- removes link to the docs about `ReactCSSTransitionGroup` and
`ReactTransitionGroup` from the main navigation
- updates 'prev' and 'next' pointers to skip this page
- adds deprecation warning to the top of the page
- remove references to these modules from the packages README
- updates 'add-ons' main page to list this as a deprecated add-on
* Update `React.createClass` to `createReactClass` in the docs
The `React.createClass` method is being deprecated in favor of
`createReactClass`.
* Remove 'React.createClass' from top level API docs
It no longer makes sense to have a section for the 'createClass' method
in this page, since it won't be available as a top level method on
'React'.
I initially was going to pull the section about 'createClass' into a
separate page to add under 'addons' but it was short and duplicative of
the 'react-without-es6' docs. So I just linked to those.
* Remove *most* `React.PropTypes` from the docs
I am doing the docs for `context` in a separate commit because that case
was a bit less clear-cut.
We will no longer support `React.PropTypes` as a built-in feature of
React, and instead should direct folks to use the `PropTypes` project
that stands alone.
Rather than retaining the `React.PropTypes` examples and just revamping
them to show the use of the stand-alone `PropTypes` library with React,
it makes more sense to direct people to that project and reduce the
perceived API area and complexity of React core. The proper place to
document `PropTypes` is in the README or docs of that project, not in
React docs.
* Update `context` docs to not use `React.PropTypes`
We use `React.PropTypes` to define the `contextType` for the `context`
feature of React. It's unclear how this will work once `React.PropTypes`
is replaced by the external `PropTypes` library. Some options;
a) Deprecate `context`, either in v16 or shortly after. Seems reasonable
based on the intense warnings against using context that we have in the
docs -
https://facebook.github.io/react/docs/context.html#why-not-to-use-context
**Except** that probably some widely used libraries depend on it, like
`React-Router`.
b) Expect users will use external `PropTypes` library when defining
`contextTypes` and just don't do our `checkReactTypeSpec` against them
any more in v16.
c) Stop masking context and pass the whole context
unmasked everywhere. Worst option, do not recommend.
I went with `b` and assume that, for now, we will get users to use the
external `PropTypes` when defining context. I will update this PR if we
want a different approach.
* Remove 'addons' items from left nav, and deprecate 'addons' doc page
The plan:
[X] Remove links to 'addons' items from main navigation
[X] Add deprecation notices where appropriate, and update syntax to show
using the separate modules.
[ ] Update other references to 'React.addons' in docs. Coming in next
commit.
--- blocked but coming in future PRs
[ ] Link to a blog post describing the new locations of add-ons in the
deprecation notice on the '/docs/addons.html' page. Blocked until we
actually publish that blog post.
[ ] Move the docs for each add-on to the actual github repo where it now
lives.
[ ] Redirect the old add-ons doc permalinks to the docs in the separate
github repos for those modules.
[ ] Remove the old add-ons doc markdown files from React core docs.
* Remove references to `React.addons` from docs
Just misc. places where we referenced the 'addons' feature. All gone!
8 years ago
import ReactTestUtils from 'react-dom/test-utils'; // ES6
var ReactTestUtils = require('react-dom/test-utils'); // ES5 with npm
```
## Overview {#overview}
`ReactTestUtils` makes it easy to test React components in the testing framework of your choice. At Facebook we use [Jest ](https://facebook.github.io/jest/ ) for painless JavaScript testing. Learn how to get started with Jest through the Jest website's [React Tutorial ](https://jestjs.io/docs/tutorial-react ).
> Note:
>
> We recommend using [React Testing Library](https://testing-library.com/react) which is designed to enable and encourage writing tests that use your components as the end users do.
>
> Alternatively, Airbnb has released a testing utility called [Enzyme](https://airbnb.io/enzyme/), which makes it easy to assert, manipulate, and traverse your React Components' output.
- [`act()` ](#act )
- [`mockComponent()` ](#mockcomponent )
- [`isElement()` ](#iselement )
- [`isElementOfType()` ](#iselementoftype )
- [`isDOMComponent()` ](#isdomcomponent )
- [`isCompositeComponent()` ](#iscompositecomponent )
- [`isCompositeComponentWithType()` ](#iscompositecomponentwithtype )
- [`findAllInRenderedTree()` ](#findallinrenderedtree )
- [`scryRenderedDOMComponentsWithClass()` ](#scryrendereddomcomponentswithclass )
- [`findRenderedDOMComponentWithClass()` ](#findrendereddomcomponentwithclass )
- [`scryRenderedDOMComponentsWithTag()` ](#scryrendereddomcomponentswithtag )
- [`findRenderedDOMComponentWithTag()` ](#findrendereddomcomponentwithtag )
- [`scryRenderedComponentsWithType()` ](#scryrenderedcomponentswithtype )
- [`findRenderedComponentWithType()` ](#findrenderedcomponentwithtype )
- [`renderIntoDocument()` ](#renderintodocument )
- [`Simulate` ](#simulate )
## Reference {#reference}
### `act()` {#act}
To prepare a component for assertions, wrap the code rendering it and performing updates inside an `act()` call. This makes your test run closer to how React works in the browser.
>Note
>
>If you use `react-test-renderer` , it also provides an `act` export that behaves the same way.
For example, let's say we have this `Counter` component:
```js
class Counter extends React.Component {
constructor(props) {
super(props);
this.state = {count: 0};
this.handleClick = this.handleClick.bind(this);
}
componentDidMount() {
document.title = `You clicked ${this.state.count} times` ;
}
componentDidUpdate() {
document.title = `You clicked ${this.state.count} times` ;
}
handleClick() {
this.setState(state => ({
count: state.count + 1,
}));
}
render() {
return (
< div >
< p > You clicked {this.state.count} times< / p >
< button onClick = {this.handleClick} >
Click me
< / button >
< / div >
);
}
}
```
Here is how we can test it:
```js{3,20-22,29-31}
import React from 'react';
import ReactDOM from 'react-dom';
import { act } from 'react-dom/test-utils';
import Counter from './Counter';
let container;
beforeEach(() => {
container = document.createElement('div');
document.body.appendChild(container);
});
afterEach(() => {
document.body.removeChild(container);
container = null;
});
it('can render and update a counter', () => {
// Test first render and componentDidMount
act(() => {
ReactDOM.render(< Counter / > , container);
});
const button = container.querySelector('button');
const label = container.querySelector('p');
expect(label.textContent).toBe('You clicked 0 times');
expect(document.title).toBe('You clicked 0 times');
// Test second render and componentDidUpdate
act(() => {
button.dispatchEvent(new MouseEvent('click', {bubbles: true}));
});
expect(label.textContent).toBe('You clicked 1 times');
expect(document.title).toBe('You clicked 1 times');
});
```
Don't forget that dispatching DOM events only works when the DOM container is added to the `document` . You can use a helper like [`react-testing-library` ](https://github.com/kentcdodds/react-testing-library ) to reduce the boilerplate code.
* * *
### `mockComponent()` {#mockcomponent}
```javascript
mockComponent(
componentClass,
[mockTagName]
)
```
Pass a mocked component module to this method to augment it with useful methods that allow it to be used as a dummy React component. Instead of rendering as usual, the component will become a simple `<div>` (or other tag if `mockTagName` is provided) containing any provided children.
> Note:
>
> `mockComponent()` is a legacy API. We recommend using [shallow rendering](/docs/shallow-renderer.html) or [`jest.mock()`](https://facebook.github.io/jest/docs/en/tutorial-react-native.html#mock-native-modules-using-jestmock) instead.
* * *
### `isElement()` {#iselement}
```javascript
isElement(element)
```
Returns `true` if `element` is any React element.
* * *
### `isElementOfType()` {#iselementoftype}
```javascript
isElementOfType(
element,
componentClass
)
```
Returns `true` if `element` is a React element whose type is of a React `componentClass` .
* * *
### `isDOMComponent()` {#isdomcomponent}
```javascript
isDOMComponent(instance)
```
Returns `true` if `instance` is a DOM component (such as a `<div>` or `<span>` ).
* * *
### `isCompositeComponent()` {#iscompositecomponent}
```javascript
isCompositeComponent(instance)
```
Returns `true` if `instance` is a user-defined component, such as a class or a function.
* * *
### `isCompositeComponentWithType()` {#iscompositecomponentwithtype}
```javascript
isCompositeComponentWithType(
instance,
componentClass
)
```
Returns `true` if `instance` is a component whose type is of a React `componentClass` .
* * *
### `findAllInRenderedTree()` {#findallinrenderedtree}
```javascript
findAllInRenderedTree(
tree,
test
)
```
Traverse all components in `tree` and accumulate all components where `test(component)` is `true` . This is not that useful on its own, but it's used as a primitive for other test utils.
* * *
### `scryRenderedDOMComponentsWithClass()` {#scryrendereddomcomponentswithclass}
```javascript
scryRenderedDOMComponentsWithClass(
tree,
className
)
```
Finds all DOM elements of components in the rendered tree that are DOM components with the class name matching `className` .
* * *
### `findRenderedDOMComponentWithClass()` {#findrendereddomcomponentwithclass}
```javascript
findRenderedDOMComponentWithClass(
tree,
className
)
```
Like [`scryRenderedDOMComponentsWithClass()` ](#scryrendereddomcomponentswithclass ) but expects there to be one result, and returns that one result, or throws exception if there is any other number of matches besides one.
* * *
### `scryRenderedDOMComponentsWithTag()` {#scryrendereddomcomponentswithtag}
```javascript
scryRenderedDOMComponentsWithTag(
tree,
tagName
)
```
Finds all DOM elements of components in the rendered tree that are DOM components with the tag name matching `tagName` .
* * *
### `findRenderedDOMComponentWithTag()` {#findrendereddomcomponentwithtag}
```javascript
findRenderedDOMComponentWithTag(
tree,
tagName
)
```
Like [`scryRenderedDOMComponentsWithTag()` ](#scryrendereddomcomponentswithtag ) but expects there to be one result, and returns that one result, or throws exception if there is any other number of matches besides one.
* * *
### `scryRenderedComponentsWithType()` {#scryrenderedcomponentswithtype}
```javascript
scryRenderedComponentsWithType(
tree,
componentClass
)
```
Finds all instances of components with type equal to `componentClass` .
* * *
### `findRenderedComponentWithType()` {#findrenderedcomponentwithtype}
```javascript
findRenderedComponentWithType(
tree,
componentClass
)
```
Same as [`scryRenderedComponentsWithType()` ](#scryrenderedcomponentswithtype ) but expects there to be one result and returns that one result, or throws exception if there is any other number of matches besides one.
***
### `renderIntoDocument()` {#renderintodocument}
```javascript
renderIntoDocument(element)
```
Render a React element into a detached DOM node in the document. **This function requires a DOM.** It is effectively equivalent to:
```js
const domContainer = document.createElement('div');
ReactDOM.render(element, domContainer);
```
> Note:
>
> You will need to have `window`, `window.document` and `window.document.createElement` globally available **before** you import `React`. Otherwise React will think it can't access the DOM and methods like `setState` won't work.
* * *
## Other Utilities {#other-utilities}
### `Simulate` {#simulate}
```javascript
Simulate.{eventName}(
element,
[eventData]
)
```
Simulate an event dispatch on a DOM node with optional `eventData` event data.
`Simulate` has a method for [every event that React understands ](/docs/events.html#supported-events ).
**Clicking an element**
```javascript
// < button ref = {(node) = > this.button = node}>...< / button >
const node = this.button;
ReactTestUtils.Simulate.click(node);
```
**Changing the value of an input field and then pressing ENTER.**
```javascript
// < input ref = {(node) = > this.textInput = node} />
const node = this.textInput;
node.value = 'giraffe';
ReactTestUtils.Simulate.change(node);
ReactTestUtils.Simulate.keyDown(node, {key: "Enter", keyCode: 13, which: 13});
```
> Note
>
> You will have to provide any event property that you're using in your component (e.g. keyCode, which, etc...) as React is not creating any of these for you.
* * *