Enter Your Email Address to Watch This Lesson

Your link to unlock this lesson will be sent to this email address.

Unlock this lesson and all 983 of the free egghead.io lessons, plus get React content delivered directly to your inbox!



Existing egghead members will not see this. Sign in.

React Testing: Running tests

1:54 React lesson by

In this lesson, we walk through how to setup our tests and run them. We write a quick empty first test and assertion, so we can run the tests. Using Mocha, we can do this manually each time with the Mocha CLI. We can also automate this using task runner features from tools like Grunt, Gulp, Webpack, or npm scripts. In this course, we will use the common npm test script setup to run our tests. We will also use the Babel compiler to write our tests with modern JavaScript syntax.

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

In this lesson, we walk through how to setup our tests and run them. We write a quick empty first test and assertion, so we can run the tests. Using Mocha, we can do this manually each time with the Mocha CLI. We can also automate this using task runner features from tools like Grunt, Gulp, Webpack, or npm scripts. In this course, we will use the common npm test script setup to run our tests. We will also use the Babel compiler to write our tests with modern JavaScript syntax.

Avatar
Jason

Initially, I was getting the following error:

(function (exports, require, module, __filename, __dirname) { import expect from 'expect';

In order to get the empty test to work, I had to create a .babelrc file in my project root with the following content:

{
    "presets": ["es2015"]
}
Avatar
Trevor

Yes. The code example for the lesson has this.

In reply to Jason
Avatar
Jaga Santagostino

Thanks a lot, this is was a pain the the @$$.

Also works in package.json in this way

"react-addons-test-utils": "^0.14.5"

},
"babel": {
"presets": [
"es2015",
]
}

ps: how do i format code? ```language-json not working as expected

In reply to Jason
Avatar
Trevor

Jaga, glad this was helpful! I believe the Egghead markdown doesn't support full
```code
comments.

In reply to Jaga Santagostino
Avatar
Joe

This bit me too. Thanks for the solution.

In reply to Jason
Avatar
Ionut

Hello,

Any idea how to add coverage here?

Thanks,
Ionut

Avatar
Trevor

Hi Ionut,

Since this lesson is just using Mocha under the hood, any approach to adding test coverage reports with Mocha will work for this too; it doesn't matter if you are testing React, pure JS, or another language. Here is some information on Stack Overflow about this: http://stackoverflow.com/questions/16633246/code-coverage-with-mocha

One thing to keep in mind is that if you are using ES2015 syntax via Babel with Mocha (like we are in this lesson), you will need to have some extra config to account for it. Here is a tutorial that walks through setting up test coverage with Mocha with Babel: https://drublic.de/blog/es6-modules-using-browserify-mocha/

Hope this helps :)

In reply to Ionut
Avatar
Dean

Trevor,

I notice you put your test files in the same dirs as the files you are testing. I am curious why you didn't go with the convention of a 'test' dir, and have the corresponding dir structure of the things you are testing etc.. like a mirror image, but with '.spec' (or .test) files only? Is there anything to gain or loss either way?

Avatar
Trevor

Hi Dean,

It is totally up to you. I've worked it both types of codebases. It really doesn't make a difference in how your tests run - just where they are placed. It is just like how a few years ago people mostly split their projects into "scripts" (all .js files), and "styles" (all .css files) - but more and more people are organizing by feature so you have a UnreadActivityIndicator which includes your scripts, styles, etc. I prefer to also put my tests with the feature it is testing so that everything related to the component/module is in one place. But it totally works to have a root "tests" folder as well :)

In reply to Dean
Avatar
Trevor

I especially like to have my tests next to what they are testing because when I import the thing that is being tested, I can do:

import ThingBeingTested from './ThingBeingTested';

Instead of...

import ThingBeingTested from '../src/components/SomeParentComponent/ThingBeingTested';

Keeps everything related together so you can move a component folder wherever you want and your imports wont break.

But you can do it either way :)

In reply to Trevor
Avatar
Dean

Thanks for your prompt response! I do have one more question if I may. You use React.utils library -- for the component checking stuff, I am curious why you didn't go the route of jsdom? Do you feel one never has to get that granular with the child components etc? Or ?

In reply to Trevor
Avatar
Rajitha

How are you getting those suggestions as you type?

Avatar
Rajitha

package name or anything?

In reply to Rajitha
Avatar
Eric

Which course should we do first - it looks like you have code already going in lesson 1?

Avatar
Omar Eduardo

The course uses the code from github

In reply to Eric
Avatar
Ben

This course seems to be missing a step at the end of lesson 1 that says "go to the github repository, copy the package.json there and npm install all the other dependencies that we haven't mentioned.

I followed lesson 1 exactly, but now at the beginning of lesson 2, my package.json is suddenly wildly different to what is being shown in the video with no explanation. It's fine for me - I know to go get the packages from github - but for a beginner this would be incredibly confusing. :(

Avatar
Julian

How are you getting those suggestions as you type?

I too would like to know this.

In reply to Rajitha
Avatar
saurabh

you should mention it in your tutorial.

In reply to Trevor
Avatar
Shawn

In the Mocha docs, they discourage using the es6 arrow function because it fails tests that use the Mocha context (https://mochajs.org/#arrow-functions). If they discourage it and anything using Mocha's this context fails, shouldn't we just use standard functions for every Mocha test?

Just wondering if there should be a warning somewhere in the course. Thank you for creating this course though, nice work!

In reply to egghead.io

To set up my project to run my tests, I'm going to go into my package.json, and then inside of my scripts block, and I'm going to create a new test script. Inside of this script, I'm going to use the Mocha CLI that we've already installed, and then I need to tell it what test files to run.

We're going to be placing our test files inside of source, and then in any folder, and they will have a .spec.js extension. You could use any extensions here to say that this is a test file. Some people use .test.js, or -test.js, or place these in their own test folder, but this is the convention we'll be using in this course.

Finally, I'm using Babel as a compiler to compile my React code and my ECMAScript 2016-2015 code back into JavaScript that will in the browser today. I need to add on the compilers flag, so I'll say compilers, and then I need to tell it to run Babel core, and now we'll be able to use modern syntax in all of our test files.

To make sure our test script is working, I've created a new file with a .spec.js extension. Let's write a basic test in there, and then we'll run it. First, I need to import our assertion library, so I'll import Expect. Next, I'll create a describe block, which Mocha gives us to describe our tests. This'll just be an empty test.

Now for our test itself, we're going to use an it block, which Mocha gives us, and say that it should work. Finally, we'll use our Expect package to assert that true is going to equal true. To run our test, I'll jump over to my command line and type NPM test. We can see that our test is passing.



HEY, QUICK QUESTION!
Joel's Head
Why are we asking?