take a look at React with Mocha, Chai & Enzyme

Advisable different: As a substitute of Mocha/Chai, utilizing Jest as take a look at runner and assertion library for unit, integration and snapshot checks.

Earlier than organising the take a look at setup with completely different testing libraries and writing the React part checks, you will want a easy React utility which may be examined within the first place. You’ll introduce a easy App part which may be examined within the following sections. If it is too tough so that you can observe the following elements of the React utility, you must seize a replica of The Street to be taught React to find out about React itself earlier than testing a React utility.

Let’s begin within the src/index.js file. Right here you may import the App part which isn’t carried out but and render it.

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
ReactDOM.render(
  <App />,
  doc.getElementById('app')
);
The App part is an JavaScript ES6 class part that has its personal state. It is a Counter part the place it needs to be doable to increment and decrement a digit by clicking on both of two buttons. The file for the App part needs to be situated in src/App.js.
import React, { Part } from 'react';
class App extends Part {
  constructor() {
    tremendous();
    this.state = {
      counter: 0,
    };
    this.onIncrement = this.onIncrement.bind(this);
    this.onDecrement = this.onDecrement.bind(this);
  }
  onIncrement() {
    this.setState((prevState) => ({
      counter: prevState.counter + 1,
    }));
  }
  onDecrement() {
    this.setState((prevState) => ({
      counter: prevState.counter - 1,
    }));
  }
  render() {
    const { counter } = this.state;
    return (
      <div>
        <h1>My Counter</h1>
        <p>{counter}</p>
        <button
          sort="button"
          onClick={this.onIncrement}
        >
          Increment
        </button>
        <button
          sort="button"
          onClick={this.onDecrement}
        >
          Decrement
        </button>
      </div>
    );
  }
}
export default App;
To this point, hopefully every little thing needs to be clear on how this part works. If it isn’t clear, make certain to seize the book/course “The Street to be taught React” after studying this tutorial.
However that is not it for the use case utility. Let’s add a few extra issues for the sake of testing completely different elements of it in isolation afterward. Because the this.setState() methodology is asynchronously executed, it already makes use of a perform as an alternative of an object. That method, it will probably entry the state when this.setState() is definitely executed asynchronously. That is just one advantage of utilizing the perform over the thing in this.setState(). As well as, it is also doable to extract it as standalone perform which may be examined in isolation from the part afterward.
import React, { Part } from 'react';
const doIncrement = (prevState) => ({
  counter: prevState.counter + 1,
});
const doDecrement = (prevState) => ({
  counter: prevState.counter - 1,
});
class App extends Part {
  constructor() {
    ...
  }
  onIncrement() {
    this.setState(doIncrement);
  }
  onDecrement() {
    this.setState(doDecrement);
  }
  render() {
    ...
  }
}
export default App;
With a purpose to import these features within the checks afterward , they should be exported from the file.
import React, { Part } from 'react';
export const doIncrement = (prevState) => ({
  counter: prevState.counter + 1,
});
export const doDecrement = (prevState) => ({
  counter: prevState.counter - 1,
});
class App extends Part {
 ...
}
export default App;
These features that are used to replace the native state of the React part can examined in isolation from the part now. That is what you’ll name an actual unit take a look at afterward. The perform is examined with an enter and the take a look at asserts an anticipated output. There aren’t any unintended effects, as a result of the perform is pure.
As well as for our React utility, let’s introduce a second part to have a relationship between two elements as mother or father and little one elements. That is one other situation which may be examined as integration take a look at afterward. Should you would take a look at every part in isolation, you’ll have unit checks. However by testing them collectively of their context, you’ve gotten an integration take a look at between each elements.
...
class App extends Part {
  ...
  render() {
    const { counter } = this.state;
    return (
      <div>
        <h1>My Counter</h1>
        <Counter counter={counter} />
        <button
          sort="button"
          onClick={this.onIncrement}
        >
          Increment
        </button>
        <button
          sort="button"
          onClick={this.onDecrement}
        >
          Decrement
        </button>
      </div>
    );
  }
}
export const Counter = ({ counter }) =>
  <p>{counter}</p>
export default App;
As you may see, the part will get exported as properly. This fashion, it may be imported within the take a look at in a later part of this tutorial. Regardless that the Counter part just isn’t used anyplace else in the entire utility, it’s okay to export elements (and features) from a file for the sake of testing them. That is it for the use case utility which shall be examined within the following sections.
Mocha with Chai Take a look at Setup in React
This part will present you the way to setup and carry out React testing with Mocha, Chai and Enzyme. Let’s implement a minimal React testing setup to make first assertions for the exported features. First, there must be an entity which is accountable to run all of our checks in a sure framework. This entity might be Mocha which is a well-liked take a look at runner in React purposes. In distinction, one other in style take a look at runner is Karma which is in style for testing Angular purposes.
Let’s set up Mocha on the command line as growth dependency.
npm set up --save-dev mocha
Second, there must be an entity which can be utilized to make assertions. Somebody has to in a position to say: “Count on X to be equal to Y”. This entity might be Chai in our testing setup. So let’s set up it on the command line as properly.
npm set up --save-dev chai
Final however not least, React elements want some form of synthetic browser setting, as a result of they render HTML within the browser’s DOM. Because the checks should not executed in an actual browser, it’s good to setup the minimal setting for the part checks your self. That is why it’s good to set up jsdom on the command line as dev dependency as properly. Jsdom makes positive you could create this synthetic browser setting within the subsequent steps.
npm set up --save-dev jsdom
These three libraries are every little thing you want for a minimal take a look at setting. You’ll use these to check a few issues within the following. Afterward, you’ll be taught within the subsequent sections about superior libraries to counterpoint your React part testing instrument set.
Within the final step of this part, let’s have a look at how these three libraries are configured collectively as a way to begin testing your utility. On the command line, create the mandatory information as take a look at configurations in a brand new take a look at folder. In your undertaking, create subsequent to your src/ folder a take a look at/ folder for all of your take a look at configuration.
mkdir take a look at
cd take a look at
contact helpers.js dom.js
Each information might be full of content material now. Afterward, they are going to be used as configuration to run the checks through a script on the command line. Let’s go first with the take a look at/helpers.js file:
import { anticipate } from 'chai';
world.anticipate = anticipate;
The one factor we’re doing on this file is importing the anticipate perform from the chai assertion library. This perform is used afterward in your checks to claim: “Count on X to be equal to Y”. Moreover, the anticipate perform is made globally accessible in all of your take a look at information through the use of this file. That is how one can make anticipate() the default perform in your checks with out importing the perform in every file explicitly. It is all the time there in each of your take a look at information, as a result of you will want it anyway in each take a look at. Within the following sections, you’ll add extra of those globally accessible take a look at features, as a result of you probably want them in each take a look at anyhow.
Within the different file, the take a look at/dom.js file, you’ll setup your pseudo browser setting on your React elements which render HTML ultimately. Open the take a look at/dom.js file and add the next strains to it:
import { JSDOM } from 'jsdom';
const { window } = new JSDOM('<!doctype html><html><physique></physique></html>');
perform copyProps(src, goal) {
  const props = Object.getOwnPropertyNames(src)
    .filter(prop => typeof goal[prop] === 'undefined')
    .cut back((consequence, prop) => ({
      ...consequence,
      [prop]: Object.getOwnPropertyDescriptor(src, prop),
    }), {});
  Object.defineProperties(goal, props);
}
world.window = window;
world.doc = window.doc;
world.navigator = {
  userAgent: 'node.js',
};
copyProps(window, world);
This tutorial is not going to clarify the final code snippet in an excessive amount of element. Principally the code snippet helps us to imitate the browser for our React part checks. You possibly can see that the jsdom library is used to create a window object which needs to be accessible within the browser, but in addition a few extra objects (e.g. doc object). Don’t be concerned an excessive amount of about this file, as a result of most definitely you’ll by no means have to the touch it once more.
Now you’ve gotten each helper information on your checks in place. One to show features out of your take a look at libraries globally to all of your take a look at information, as a result of they’re wanted anyway, and one to imitate the DOM on your React part checks. Final however not least, it’s good to outline the npm run take a look at script in your package deal.json. This script ought to execute all of your take a look at information, which have a selected suffix of their file title, and use the 2 beforehand outlined information as configuration for the take a look at setting. In your package deal.json add the next script:
"scripts": {
  "begin": "webpack serve --config ./webpack.config.js",
  "take a look at:unit": "mocha --require @babel/register --require ./take a look at/helpers.js --require ./take a look at/dom.js 'src/**/*.spec.js'"
},
If you have not put in @babel/register which is used within the npm script but, you are able to do it with npm set up -save-dev @babel/register.
As you may see, the script takes each configuration information as required take a look at configuration and executes all take a look at information which finish with the suffix “.spec.js”. Principally a take a look at file may very well be named App.spec.js and it needs to be someplace within the /src* folder. In fact, you may give you your individual guidelines for the take a look at file naming right here. It is as much as you.
The script may be executed by operating npm run take a look at:unit on the command line now, however it won’t discover any checks but, as a result of you’ll have to outline these checks within the first place. You’ll do it within the subsequent part, however earlier than doing so, you may add a second npm script. This script will execute the beforehand outlined script, however this time in watch mode.
"scripts": {
  "begin": "webpack serve --config ./webpack.config.js",
  "take a look at:unit": "mocha --require @babel/register --require ./take a look at/helpers.js --require ./take a look at/dom.js 'src/**/*.spec.js'",
  "take a look at:unit:watch": "npm run take a look at:unit -- --watch"
},
The watch mode signifies that your checks will run as soon as, however each time once more whenever you change your supply code or checks. That is how you’re going to get instant suggestions on the command line whereas creating your utility, doing take a look at pushed growth, implementing extra checks, or while you’re altering checks.
Be aware: If you wish to run your checks in watch mode with npm run take a look at:unit:watch alongside together with your growth server with npm begin, it’s good to open two terminal tabs to have the ability to execute each scripts aspect by aspect.
Final however not least, earlier than diving into testing with Mocha and Chai, there’s one neat little library which you’ll want afterward. It is referred to as ignore-styles. In some unspecified time in the future, it’s possible you’ll introduce styling on your React elements. Nonetheless, the styling should not essentially have an effect on the checks and thus it’s possible you’ll wanna simply ignore them. That is the place this little library comes into play. You possibly can set up it on the command line with npm set up --save-dev ignore-styles and add it to your npm script:
"scripts": {
  "begin": "webpack serve --config ./webpack.config.js",
  "take a look at:unit": "mocha --require @babel/register --require ./take a look at/helpers.js --require ./take a look at/dom.js --require ignore-styles 'src/**/*.spec.js'",
  "take a look at:unit:watch": "npm run take a look at:unit -- --watch"
},
That is it for the Mocha and Chai setup for a React utility. Within the subsequent part, you’ll introduce your first unit checks with it.
React Unit Assessments
Let’s begin with the smallest constructing blocks within the testing pyramid: unit checks. They solely take a look at small elements of your utility in isolation. For example, features are an ideal candidates for unit checks. They solely take an enter and return an output. That is what makes pure features so highly effective for testing too, since you by no means have to fret about any side-effects. The output needs to be all the time the identical when the enter stays the identical. Thus a unit take a look at may very well be used to check this explicit perform as part of your utility in isolation.
Within the App part, you’ve gotten already extracted the features which replace the state in this.setState(). These features bought exported too, so you may import them in a take a look at file as a way to take a look at them. Let’s create a take a look at file for the App part on the command line from the src/ folder, Make certain to offer the file the right naming suffix.
contact App.spec.js
Now open up the file and add the next strains to it:
describe('Native State', () => {
  it('ought to increment the counter in state', () => {
  });
  it('ought to decrement the counter in state', () => {
  });
});
Principally the earlier strains have outlined one take a look at suite and two checks for it. Whereas the “describe”-block defines the take a look at suite, the “it”-blocks outline the take a look at circumstances. A take a look at can both achieve success (inexperienced) or inaccurate (crimson). In fact, you need to make and maintain them inexperienced.
Now it is as much as you to check each features which replace the React part state out of your src/App.js file. Whereas one perform increments the counter property within the object (state), the opposite perform decrements the counter property.
The only process to jot down a take a look at in a “it”-block in three steps is the next: prepare, act, assert.
import { doIncrement, doDecrement } from './App';
describe('Native State', () => {
  it('ought to increment the counter in state', () => {
    const state = { counter: 0 };
    const newState = doIncrement(state);
    anticipate(newState.counter).to.equal(1);
  });
  it('ought to decrement the counter in state', () => {
    const state = { counter: 0 };
    const newState = doDecrement(state);
    anticipate(newState.counter).to.equal(-1);
  });
});
Within the first line of every take a look at, you prepare the preliminary state object which would be the enter of your perform to be examined within the subsequent step. Within the second line of every take a look at, you’ll go the variable from the setup step to your perform. The perform returns a worth. Within the final line of the take a look at, you need to assert that the returned worth from the perform is an anticipated worth. On this case, the doIncrement() perform ought to increment the counter property within the state object and the doDecrement() perform ought to decrement it.
That is it. You possibly can run each checks on the command line with npm run take a look at:unit or npm run take a look at:unit:watch. You possibly can change the assertion and see how the checks behave in watch mode. They may both fail or succeed. Moreover, observe that there is no such thing as a React dependency but within the take a look at file. It is solely Mocha and Chai that are in a position to take a look at your vanilla JavaScript features. You would not even want the take a look at/dom.js configuration but, as a result of there is no such thing as a DOM of the browser wanted for these unit checks.
Enzyme Take a look at Setup in React
The next part will present you the way to setup and carry out React testing with Enzyme which makes it easy to check React elements with unit and integration checks. It’s a library by Airbnb which was launched for part checks in React. Let’s undergo the setup of Enzyme in React. First, it’s a must to set up it on the command line as dev dependency:
npm set up --save-dev enzyme
Enzyme launched adapters to play properly with React. That is why it’s a must to set up such an adapter on your take a look at setup too. The model of it is dependent upon your React model:
npm set up --save-dev enzyme-adapter-react-16
On this React testing information, we’re utilizing React 16. That is why the Enzyme adapter for React 16 will get put in right here. So make certain to examine your individual React model in your utility.
Final however not least, you may setup Enzyme in your take a look at/helpers.js file. There you may configure the adapter and expose the enzyme functionalities globally subsequent to the anticipate perform:
import { anticipate } from 'chai';
import { mount, render, shallow, configure} from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';
configure({ adapter: new Adapter() });
world.anticipate = anticipate;
world.mount = mount;
world.render = render;
world.shallow = shallow;
Much like the anticipate perform from chai which is used to make assertions, you can also make shallow, render and mount from Enzyme globally accessible. That method, you need not import it explicitly in your take a look at information anymore. You’ll use these three features on your unit and integration checks with Enzyme on your React elements.
React Testing with Enzyme: Unit and Integrations Assessments for React Elements
The Enzyme setup is up and operating. Now you can begin to check your part(s). The next part ought to present you a few fundamental patterns which you’ll be able to apply in your React part checks. Should you observe these patterns, you do not have to make a expensive psychological determination each time on the way to take a look at your React elements.
You might have already exported the Counter part from the src/App.js file. So it needs to be doable to check for you that an occasion of the Counter part is rendered whenever you render the App part. You possibly can merely add your checks within the src/App.spec.js file.
import React from 'react';
import App, { doIncrement, doDecrement, Counter } from './App';
describe('Native State', () => {
 ...
});
describe('App Part', () => {
  it('renders the Counter wrapper', () => {
    const wrapper = shallow(<App />);
    anticipate(wrapper.discover(Counter)).to.have.size(1);
  });
});
The shallow() perform is among the three features (shallow, mount, render) which you’ve gotten made accessible globally within the take a look at/helpers.js file. Shallow is the only type of rendering a part with Enzyme. It solely renders the part however not the content material of elements that are kids to this part. It makes it doable to check the part in isolation. Thus it may be used completely for unit checks of React elements. Within the earlier take a look at, you solely checked whether or not the Counter part is rendered as part occasion within the App part. Accordingly to the take a look at, there needs to be just one Counter part.
That is one easy unit take a look at you are able to do with Enzyme in React. For example, you too can examine whether or not particular HTML tags or HTMLS parts with CSS courses are rendered.
it('renders the Listing wrapper with record parts', () => {
  const wrapper = shallow(<Listing objects={['a', 'b']} />);
  anticipate(wrapper.discover('li')).to.have.size(2);
  anticipate(wrapper.discover('.record')).to.have.size(1);
});
Relying on the handed props, you may examine the rendered HTML parts by choosing them with Enzyme’s selectors. This fashion, you too can examine a conditional rendering in React by asserting the size of a variety to be both 0 or 1.
Shallow rendering checks with Enzyme will also be used for light-weight integration checks. For example, whereas the final take a look at checked solely the rendered HTML tags, the following take a look at asserts whether or not the right props are handed to the following part.
...
describe('App Part', () => {
  it('renders the Counter wrapper', () => {
    const wrapper = shallow(<App />);
    anticipate(wrapper.discover(Counter)).to.have.size(1);
  });
  it('passes all props to Counter wrapper', () => {
    const wrapper = shallow(<App />);
    let counterWrapper = wrapper.discover(Counter);
    anticipate(counterWrapper.props().counter).to.equal(0);
    wrapper.setState({ counter: -1 });
    counterWrapper = wrapper.discover(Counter);
    anticipate(counterWrapper.props().counter).to.equal(-1);
  });
});
The road between a unit take a look at and a integration take a look at may be blurry. However on this case, you would say it is a light-weight integration take a look at as a result of it checks whether or not two elements play collectively as anticipated. The final take a look at has proven you the way to entry and confirm props that are handed from part to part and the way to manipulate the native state of a part for the aim of your take a look at. That method, you too can take a look at your React part state when the native state adjustments. For example, think about a toggle for a conditional rendering once more which is saved as native state in your part. You possibly can manipulate the state and confirm whether or not the right HTML parts are rendered or not rendered.
You might have seen the way to take a look at the rendered output, the way to entry props and the way to manipulate the native state of a part. Subsequent, you too can simulate clicks with Enzyme. Your App part has two buttons that are completely suited to check the clicking habits. Whereas one button ought to increment the counter within the native state of the React part, the opposite button ought to decrement the counter. Let’s examine how one can simulate these occasions in interactive HTML parts resembling buttons with a onClick handler.
...
describe('App Part', () => {
  it('renders the Counter wrapper', () => {
    const wrapper = shallow(<App />);
    anticipate(wrapper.discover(Counter)).to.have.size(1);
  });
  it('passes all props to Counter wrapper', () => {
    const wrapper = shallow(<App />);
    let counterWrapper = wrapper.discover(Counter);
    anticipate(counterWrapper.props().counter).to.equal(0);
    wrapper.setState({ counter: -1 });
    counterWrapper = wrapper.discover(Counter);
    anticipate(counterWrapper.props().counter).to.equal(-1);
  });
  it('increments the counter', () => {
    const wrapper = shallow(<App />);
    wrapper.setState({ counter: 0 });
    wrapper.discover('button').at(0).simulate('click on');
    anticipate(wrapper.state().counter).to.equal(1);
  });
  it('decrements the counter', () => {
    const wrapper = shallow(<App />);
    wrapper.setState({ counter: 0 });
    wrapper.discover('button').at(1).simulate('click on');
    anticipate(wrapper.state().counter).to.equal(-1);
  });
});
Since there are two buttons, you need to use the at() helper perform to entry the specified aspect within the record of parts with an index. However watch out when the order of the weather adjustments. In a greatest case take a look at situation, I might advocate to make use of extra particular Enzyme selectors to handle every aspect individually. In any other case your checks are more likely to break when the order of your parts, on this case the order of the button parts, adjustments.
The final take a look at circumstances have been easy methods for testing your React state. They are often seen as take a look at sample, as a result of you may simply repeat them for different elements too. It should not take you a lot time to confirm that essential HTML parts or React elements are rendered, the right props are handed and the native state is manipulated in an anticipated method.
You might have solely used the shallow() perform from Enzyme on your unit checks and light-weight integration checks to date. You might marvel when you must use the mount() and render() features from Enzyme.
Whereas shallow() solely renders the part with out the content material of kid elements, mount() renders all little one elements as properly. It renders the entire part hierarchy. Whereas the previous is used for part checks in isolation (unit checks, light-weight integration), the latter is used for actual integration checks. Integration checks usually tend to break, as a result of they embody all the youngsters and logic of your part tree. Thus the upkeep prices are greater for integration checks. Persons are saying it is dearer to jot down and preserve these checks than unit checks. Final however not least, the third perform to render your React elements with Enzyme known as render(). It’s much like mount(), as a result of it renders all little one elements. However from a efficiency perspective, it’s cheaper than mount(), as a result of it would not run the lifecycle strategies of your part. So in case you want entry to little one elements however should not considering lifecycle strategies, you need to use render() as an alternative of mount().
There are two main philosophies on what number of unit and integration checks you must have on your elements in your utility. The frequent testing pyramid says that you must have numerous unit checks and a number of other integration checks (and just a few end-to-end checks). Principally, you must have quite a lot of small maintainable unit checks, however just a few important integration checks. It is the frequent method for testing in software program engineering. Nonetheless, for part checks (like in React) there exists the philosophy to have many integration checks however just a few unit checks. Unit checks should not very more likely to break as a result of they isolate the part an excessive amount of from the remainder of the applying. They mock the context completely away. That is why individuals argue towards it, as a result of the part is just too remoted. In conclusion, you’ll be extra more likely to take a look at a part for its robustness through the use of integration checks to check them of their context of different elements.
What does it imply for the implementation of your checks? Should you would need to use extra integration checks than unit checks, you’ll go for mount() or render() as an alternative of shallow() in your part checks. That method you render, take a look at and confirm the existence and habits of the entire part tree. Furthermore, you’ll be capable to write extra complicated checks as a result of you’ve gotten entry to all little one elements. The take a look at circumstances will not differ an excessive amount of from the beforehand carried out take a look at circumstances. You’ll nonetheless confirm handed props, rendered parts, simulated clicks and state adjustments of your native React state.
Sinon Take a look at Setup in React
What about async checks in a React utility? To this point every little thing you’ve gotten examined was synchronous. Should you examine once more your App part, there is no such thing as a want to check one thing that’s executed asynchronously. Let’s introduce a synthetic situation in your App part the place some made up information is fetched within the componentDidMount() lifecycle methodology.
Usually it occurs {that a} part requests information from a third-party API within the componentDidMount() lifecycle methodology. Due to it, it needs to be doable to check this asynchronous half in a React part as properly. Let’s faux there’s a pseudo API endpoint that returns an array of counters from an API. In fact, it won’t work in your operating utility, as a result of the API endpoint would not exist, however it needs to be there for the aim of testing it. Afterward, you must be capable to take a look at your individual third-party requests that occur within the componentDidMount() lifecycle methodology.
Within the following situation, you’ll use axios to make the request to the third-party API. Due to this fact, it’s a must to set up the axios package deal with npm on the command line.
npm set up --save axios
Afterward, you can also make the request to a pseudo API endpoint. It is as much as you to make use of an actual API endpoint for this situation. If you’re not acquainted on the way to make request to third-party APIs in React elements, checkout this information on information fetching in React.
import React, { Part } from 'react';
import axios from 'axios';
...
class App extends Part {
  constructor() {
    tremendous();
    this.state = {
      counter: 0,
      asyncCounters: null,
    };
    this.onIncrement = this.onIncrement.bind(this);
    this.onDecrement = this.onDecrement.bind(this);
  }
  componentDidMount() {
    axios.get('http://mypseudodomain/counter')
      .then(counter => this.setState({ asyncCounters: counter }))
      .catch(error => console.log(error));
  }
  onIncrement() {
    this.setState(doIncrement);
  }
  onDecrement() {
    this.setState(doDecrement);
  }
  render() {
    ...
  }
}
...
export default App;
For the aim of testing this situation, there is no such thing as a must show the asyncCounters from the native state within the render() methodology. As a result of the endpoint will solely return faux information within the take a look at afterward. As well as, the situation solely covers the completely satisfied path when the request is profitable.
Now, how would you take a look at the asynchronous information fetching in your React part? You possibly can set up a neat library referred to as Sinon for it as dev dependency on the command line:
npm set up --save-dev sinon
Afterward, you may add Sinon as one other world perform to your take a look at/helpers.js file:
import sinon from 'sinon';
import { anticipate } from 'chai';
import { mount, render, shallow, configure} from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';
configure({ adapter: new Adapter() });
world.anticipate = anticipate;
world.sinon = sinon;
world.mount = mount;
world.render = render;
world.shallow = shallow;
Sinon can be utilized for spies, stubs, and mocks. Within the following, you’ll use a spy and a stub for testing your asynchronous enterprise logic in your React part. These are more often than not enough for testing async logic in your code.
React Testing with Sinon: Testing Asynchronous Logic
Let’s add a primary spy only for the sake of demonstrating it. A spy can be utilized on any perform for assertions. After a spy is utilized to it, you may assert for instance what number of occasions the perform was referred to as for the take a look at.
...
describe('App Part', () => {
  it('calls componentDidMount', () => {
    sinon.spy(App.prototype, 'componentDidMount');
    const wrapper = mount(<App />);
    anticipate(App.prototype.componentDidMount.calledOnce).to.equal(true);
  });
});
Within the take a look at, you anticipated the componentDidMount() lifecycle methodology, which is on the market through the prototype chain on the App part, to be referred to as solely as soon as. If  the lifecycle strategies of React elements, it needs to be clear that this methodology is barely referred to as as soon as when the part mounts. Afterward, it isn’t referred to as once more. Thus the take a look at ought to succeed. That is basically how you’ll take a look at React lifecycle strategies.
The take a look at itself just isn’t necessary and may be eliminated once more. It ought to solely exhibit the spying capabilities of Sinon. In any case, it would not make any sense to check the lifecycle strategies of a React part. That needs to be examined by React internally. As a substitute, let’s have a look at how the asynchronous information fetching in React may be examined with Sinon.
Since each take a look at of the App part is affected by this newly executed information fetching in componentDidMount(), you can also make positive to return legitimate information for it for each take a look at through the use of the earlier than() and after() setup functionalities of Mocha.
...
describe('App Part', () => {
  earlier than(() => {
  });
  after(() => {
  });
  it('renders the Counter wrapper', () => {
    ...
  });
  ...
});
Now you may import axios to your testing suite, as a result of you will want to use a stub to it for mocking the returned information from the third-party API request.
import React from 'react';
import axios from 'axios';
import App, { doIncrement, doDecrement, Counter } from './App';
...
describe('App Part', () => {
  const consequence = [3, 5, 9];
  const promise = Promise.resolve(consequence);
  earlier than(() => {
    sinon.stub(axios, 'get').withArgs('http://mydomain/counter').returns(promise);
  });
  after(() => {
    axios.get.restore();
  });
  ...
});
So what’s a stub? The Sinon documentation says: “Take a look at stubs are features (spies) with pre-programmed habits.” That method, you’ve gotten full management over your spies. For example, you may say what a perform (e.g. get()) ought to return. You possibly can slender it down by offering a selected set of arguments too. In our case, we return a promise which resolves in an array of integers (counters) ultimately.
The earlier than() and after() features occur earlier than and after the describe() take a look at suites. Thus, each take a look at ought to pay attention to the returned promise in componentDidMount() now. By doing it this manner, no take a look at will complain in regards to the information fetching. The request will simply undergo efficiently when the part is mounted for the take a look at.
After the checks ran via, the restore() methodology on the stub within the “after”-block makes positive to revive the native habits of the get() methodology which was stubbed earlier than. This fashion, you do not run into any surprises on your different checks as a result of there’s a stub someplace hanging round in your take a look at suites.
Now, let’s take a look at the asynchronous habits in componentDidMount(). The take a look at ought to assert that the returned array is saved within the native state of the React part as asyncCounters.
...
describe('App Part', () => {
  const consequence = [3, 5, 9];
  const promise = Promise.resolve(consequence);
  earlier than(() => {
    sinon.stub(axios, 'get').withArgs('http://mydomain/counter').returns(promise);
  });
  after(() => {
    axios.get.restore();
  });
  ...
  it('fetches async counters', () => {
    const wrapper = shallow(<App />);
    anticipate(wrapper.state().asyncCounters).to.equal(null);
    promise.then(() => {
      anticipate(wrapper.state().asyncCounters).to.equal(consequence);
    });
  });
});
Whenever you render the App part for the primary time, the asyncCounters in your native state needs to be null. However when the promise resolves ultimately, the state needs to be equal to the required results of the promise. Now you may run your checks once more and confirm that it goes via efficiently. Congratulations, you examined asynchronous habits in your React part. Take into account that Sinon itself just isn’t strictly certain to React (identical as Mocha and Chai). You solely use it to spy features, to use stubs on them or to create extra subtle mocks.