Slow React Tests #116

Closed
TYRONEMICHAEL opened this Issue Aug 8, 2014 · 80 comments

Comments

Projects
None yet
@TYRONEMICHAEL

Thanks for React and Jest. Loving the combo. Anyhow, I am used to running tests in livereload mode. So anytime a test file is saved, my tests are automatically run. I got this working correctly, but my tests are taking almost 3 seconds to run. That is just with one test file. I am running the files through the preprocessor, so I suspect that is where the problem lies. Do you have any suggestions on how to get the tests to run quickly or any advice on how to speed up the TDD / BDD workflow?

@gothy

This comment has been minimized.

Show comment
Hide comment
@gothy

gothy Aug 8, 2014

Hi Tyron. Had this issue with 20+ seconds for one file :)
The thing was that I've configured to just run 'jest' in the root directory. And there're LOTS of subdirs that Jest was checking for tests. Specifying a path for tests reduced this time more than 10 times now. And I've got a coffee preprocessor too. In package.json
"scripts": {
....
"test": "jest path/to/modules/to/test"
}

BTW, are you preprocessing coffee or what? :)

gothy commented Aug 8, 2014

Hi Tyron. Had this issue with 20+ seconds for one file :)
The thing was that I've configured to just run 'jest' in the root directory. And there're LOTS of subdirs that Jest was checking for tests. Specifying a path for tests reduced this time more than 10 times now. And I've got a coffee preprocessor too. In package.json
"scripts": {
....
"test": "jest path/to/modules/to/test"
}

BTW, are you preprocessing coffee or what? :)

@TYRONEMICHAEL

This comment has been minimized.

Show comment
Hide comment
@TYRONEMICHAEL

TYRONEMICHAEL Aug 8, 2014

Thanks for getting back to me @gothy. I am using regular JS with JSX. I am just running my tests through the JSX preprocessor like the example (https://github.com/facebook/jest/tree/master/examples/react). The example is also taking about 2.5 - 3 seconds to run. The jQuery example takes less than a second. Is the JSX preprocessor meant to take so much time when processing your JSX files?

React Test

screen shot 2014-08-08 at 1 46 05 pm

jQuery Test

screen shot 2014-08-08 at 1 54 55 pm

Thanks for getting back to me @gothy. I am using regular JS with JSX. I am just running my tests through the JSX preprocessor like the example (https://github.com/facebook/jest/tree/master/examples/react). The example is also taking about 2.5 - 3 seconds to run. The jQuery example takes less than a second. Is the JSX preprocessor meant to take so much time when processing your JSX files?

React Test

screen shot 2014-08-08 at 1 46 05 pm

jQuery Test

screen shot 2014-08-08 at 1 54 55 pm

@gothy

This comment has been minimized.

Show comment
Hide comment
@gothy

gothy Aug 8, 2014

Ah, I didn't use it for JSX. Can't say anything on this processor. Maybe it's actually slow. I've found my issue with directories on a real project with loads of old stuff :)

gothy commented Aug 8, 2014

Ah, I didn't use it for JSX. Can't say anything on this processor. Maybe it's actually slow. I've found my issue with directories on a real project with loads of old stuff :)

@TYRONEMICHAEL TYRONEMICHAEL changed the title from Slow Tests to Slow React Tests Aug 8, 2014

@jeffchan

This comment has been minimized.

Show comment
Hide comment
@jeffchan

jeffchan Aug 8, 2014

I experienced a similar issue with Coffeescript preprocessor. I think the problem here is that the preprocessor tries to process your dependencies as well. If you happen to require lots of things, it slows down.

jeffchan commented Aug 8, 2014

I experienced a similar issue with Coffeescript preprocessor. I think the problem here is that the preprocessor tries to process your dependencies as well. If you happen to require lots of things, it slows down.

@hojberg

This comment has been minimized.

Show comment
Hide comment
@hojberg

hojberg Aug 8, 2014

I definitely also experience slow tests with jest :(

hojberg commented Aug 8, 2014

I definitely also experience slow tests with jest :(

@iamrandys

This comment has been minimized.

Show comment
Hide comment
@iamrandys

iamrandys Aug 10, 2014

I'm experiencing the same thing. I don't think it has to do with the preprocessing (JSX processing on this small file is fast). I commented out all of the code in the example test except one of the following require statements and the test still takes 4 seconds. As soon as I comment them out, the test takes 0.1s. I did a little digging and it looks like the HasteModuleLoader is having to process 490 required packages (_shouldMock()) and not mock them when you require the react/addons.

var React = require('react/addons');

or

var CheckboxWithLabel = require('../CheckboxWithLabel.js');

I'm experiencing the same thing. I don't think it has to do with the preprocessing (JSX processing on this small file is fast). I commented out all of the code in the example test except one of the following require statements and the test still takes 4 seconds. As soon as I comment them out, the test takes 0.1s. I did a little digging and it looks like the HasteModuleLoader is having to process 490 required packages (_shouldMock()) and not mock them when you require the react/addons.

var React = require('react/addons');

or

var CheckboxWithLabel = require('../CheckboxWithLabel.js');
@TYRONEMICHAEL

This comment has been minimized.

Show comment
Hide comment
@TYRONEMICHAEL

TYRONEMICHAEL Aug 10, 2014

I removed the following var React = require('react/addons'); and still ran the files through the preprocessor. I got maybe 0.2 second improvement. If I removed the preprocessor, I get the following results:

With the JSX preprocessor
screen shot 2014-08-10 at 5 35 22 pm

Without the JSX preprocessor
screen shot 2014-08-10 at 5 34 12 pm

I removed the following var React = require('react/addons'); and still ran the files through the preprocessor. I got maybe 0.2 second improvement. If I removed the preprocessor, I get the following results:

With the JSX preprocessor
screen shot 2014-08-10 at 5 35 22 pm

Without the JSX preprocessor
screen shot 2014-08-10 at 5 34 12 pm

@TYRONEMICHAEL

This comment has been minimized.

Show comment
Hide comment
@TYRONEMICHAEL

TYRONEMICHAEL Aug 10, 2014

I prefer Mocha over Jasmine and decided to setup a gulpfile that would build the react component then run it through the mocha test suite (snippet below).

function buildScript(file, watch) {
  var bundler = browserify(file);
  var stream;
  bundler.transform(reactify);
  stream = bundler.bundle();
  return stream.on('error', handleErrors)
  .pipe(source(file))
  .pipe(gulp.dest(buildDir + '/'))
  .pipe(mocha({ reporter: 'list' }));
}

It still has to preprocess the JSX file using reactify, but rids the warning message for slow tests. So the runtime still takes just under 2 seconds, but the actual test is about 32ms. Still deciding if using JSX is worth it.

I prefer Mocha over Jasmine and decided to setup a gulpfile that would build the react component then run it through the mocha test suite (snippet below).

function buildScript(file, watch) {
  var bundler = browserify(file);
  var stream;
  bundler.transform(reactify);
  stream = bundler.bundle();
  return stream.on('error', handleErrors)
  .pipe(source(file))
  .pipe(gulp.dest(buildDir + '/'))
  .pipe(mocha({ reporter: 'list' }));
}

It still has to preprocess the JSX file using reactify, but rids the warning message for slow tests. So the runtime still takes just under 2 seconds, but the actual test is about 32ms. Still deciding if using JSX is worth it.

@iamrandys

This comment has been minimized.

Show comment
Hide comment
@iamrandys

iamrandys Aug 10, 2014

Oh you're right. I tested the jest react example not using JSX and it went from close to 4 seconds down to 0.75 seconds. Makes me really think if it's worth it to use JSX. On a big project, it's going to get slow pretty quickly unless I have a lot of different packages. I wonder if the preprocessor is run on all 490 requires and not just that single file. There is no way it should take 3 seconds for that simple component.

Either way, I really really need my tests to be fast for my workflow. I still need to figure out how to at least run a single suite. In jasmine I could use "ddescribe" or "iit" instead of "describe" and "it" to run a single test or suite. Jest is SO nice, I just need a fast workflow now.

var React = require('react');

var CheckboxWithLabel = React.createClass({displayName: 'CheckboxWithLabel',
    getInitialState: function() {
        return { isChecked: false };
    },
    onChange: function() {
        this.setState({isChecked: !this.state.isChecked});
    },
    render: function() {
        return (
            React.DOM.label(null,
                React.DOM.input(
                    {type:"checkbox",
                        checked:this.state.isChecked,
                        onChange:this.onChange}
                ),
                this.state.isChecked ? this.props.labelOn : this.props.labelOff
            )
            );
    }
});

module.exports = CheckboxWithLabel; 

Oh you're right. I tested the jest react example not using JSX and it went from close to 4 seconds down to 0.75 seconds. Makes me really think if it's worth it to use JSX. On a big project, it's going to get slow pretty quickly unless I have a lot of different packages. I wonder if the preprocessor is run on all 490 requires and not just that single file. There is no way it should take 3 seconds for that simple component.

Either way, I really really need my tests to be fast for my workflow. I still need to figure out how to at least run a single suite. In jasmine I could use "ddescribe" or "iit" instead of "describe" and "it" to run a single test or suite. Jest is SO nice, I just need a fast workflow now.

var React = require('react');

var CheckboxWithLabel = React.createClass({displayName: 'CheckboxWithLabel',
    getInitialState: function() {
        return { isChecked: false };
    },
    onChange: function() {
        this.setState({isChecked: !this.state.isChecked});
    },
    render: function() {
        return (
            React.DOM.label(null,
                React.DOM.input(
                    {type:"checkbox",
                        checked:this.state.isChecked,
                        onChange:this.onChange}
                ),
                this.state.isChecked ? this.props.labelOn : this.props.labelOff
            )
            );
    }
});

module.exports = CheckboxWithLabel; 
@iamrandys

This comment has been minimized.

Show comment
Hide comment
@iamrandys

iamrandys Aug 10, 2014

@jeffchan was right. The all of the required code is run through the preprocessor, not just the JSX files.

Looks like the fastest solution will be to use gulp, watchify and react to only process the changed JSX files while your working. We will then be able to specify only the tests that I want to run as well. This way the JSX files only get processed once and I have control over which tests are run. Something like this would be really nice for a testing workflow.

gulp jest --tests "Checkbox*,*Form*"

Watchify will then watch for any changes that these tests depend on, and then only process the changes and then only run the tests I'm working with.

@jeffchan was right. The all of the required code is run through the preprocessor, not just the JSX files.

Looks like the fastest solution will be to use gulp, watchify and react to only process the changed JSX files while your working. We will then be able to specify only the tests that I want to run as well. This way the JSX files only get processed once and I have control over which tests are run. Something like this would be really nice for a testing workflow.

gulp jest --tests "Checkbox*,*Form*"

Watchify will then watch for any changes that these tests depend on, and then only process the changes and then only run the tests I'm working with.

@TYRONEMICHAEL

This comment has been minimized.

Show comment
Hide comment
@TYRONEMICHAEL

TYRONEMICHAEL Aug 11, 2014

@iamrandys I 100% agree with you. Jest and React are awesome, but compilation of JSX into JS is a big hinderance. Just curious how Gulp will solve the problem of having your required files (Non JSX) being run through the JSX preprocessor? Are you suggesting something like the following -http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ?

@iamrandys I 100% agree with you. Jest and React are awesome, but compilation of JSX into JS is a big hinderance. Just curious how Gulp will solve the problem of having your required files (Non JSX) being run through the JSX preprocessor? Are you suggesting something like the following -http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/ ?

@Dakuan

This comment has been minimized.

Show comment
Hide comment
@Dakuan

Dakuan Aug 11, 2014

Contributor

Yep, I'm thinking about some kind of caching layer with the gulp plugin in
working on

On 11 August 2014 08:35, Tyrone Avnit notifications@github.com wrote:

@iamrandys https://github.com/iamrandys I 100% agree with you. Jest and
React are awesome, but compilation of JSX into JS is a big hinderance. Just
curious how Gulp will solve the problem of having your required files (Non
JSX) being run through the JSX preprocessor? Are you suggesting something
like the following? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?


Reply to this email directly or view it on GitHub
#116 (comment).

Contributor

Dakuan commented Aug 11, 2014

Yep, I'm thinking about some kind of caching layer with the gulp plugin in
working on

On 11 August 2014 08:35, Tyrone Avnit notifications@github.com wrote:

@iamrandys https://github.com/iamrandys I 100% agree with you. Jest and
React are awesome, but compilation of JSX into JS is a big hinderance. Just
curious how Gulp will solve the problem of having your required files (Non
JSX) being run through the JSX preprocessor? Are you suggesting something
like the following? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?


Reply to this email directly or view it on GitHub
#116 (comment).

@iamrandys

This comment has been minimized.

Show comment
Hide comment
@iamrandys

iamrandys Aug 11, 2014

Exactly, using gulp and watchify is amazingly fast with react. Throw in
gulp-livereload to refresh your browser after each change and you have an
amazing development environment. You make any change, save and you almost
instantly see the changes in all your open browsers and all devices. Now I
just need the same thing for my TDD.

It's about like this, but use reactify instead of hbsfy.
https://gist.github.com/benhowdle89/9533185

On Mon, Aug 11, 2014 at 2:35 AM, Tyrone Avnit notifications@github.com
wrote:

@iamrandys https://github.com/iamrandys I 100% agree with you. Jest and
React are awesome, but compilation of JSX into JS is a big hinderance. Just
curious how Gulp will solve the problem of having your required files (Non
JSX) being run through the JSX preprocessor? Are you suggesting something
like the following? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?


Reply to this email directly or view it on GitHub
#116 (comment).

Exactly, using gulp and watchify is amazingly fast with react. Throw in
gulp-livereload to refresh your browser after each change and you have an
amazing development environment. You make any change, save and you almost
instantly see the changes in all your open browsers and all devices. Now I
just need the same thing for my TDD.

It's about like this, but use reactify instead of hbsfy.
https://gist.github.com/benhowdle89/9533185

On Mon, Aug 11, 2014 at 2:35 AM, Tyrone Avnit notifications@github.com
wrote:

@iamrandys https://github.com/iamrandys I 100% agree with you. Jest and
React are awesome, but compilation of JSX into JS is a big hinderance. Just
curious how Gulp will solve the problem of having your required files (Non
JSX) being run through the JSX preprocessor? Are you suggesting something
like the following? -
http://blog.avisi.nl/2014/04/25/how-to-keep-a-fast-build-with-browserify-and-reactjs/
?


Reply to this email directly or view it on GitHub
#116 (comment).

@TYRONEMICHAEL

This comment has been minimized.

Show comment
Hide comment
@TYRONEMICHAEL

TYRONEMICHAEL Aug 12, 2014

Thanks @iamrandys. Developed a quick react-component-boilerplate which uses Mocha and Chai (Jasmine can be easily substituted). Tests are extremely quick and you get the added benefit of Livereload. Use as you wish.

Thanks @iamrandys. Developed a quick react-component-boilerplate which uses Mocha and Chai (Jasmine can be easily substituted). Tests are extremely quick and you get the added benefit of Livereload. Use as you wish.

@sophiebits

This comment has been minimized.

Show comment
Hide comment
@sophiebits

sophiebits Aug 13, 2014

Member

Either way, I really really need my tests to be fast for my workflow. I still need to figure out how to at least run a single suite. In jasmine I could use "ddescribe" or "iit" instead of "describe" and "it" to run a single test or suite. Jest is SO nice, I just need a fast workflow now.

You can definitely write it.only and I believe you can do describe.only as well.

Member

sophiebits commented Aug 13, 2014

Either way, I really really need my tests to be fast for my workflow. I still need to figure out how to at least run a single suite. In jasmine I could use "ddescribe" or "iit" instead of "describe" and "it" to run a single test or suite. Jest is SO nice, I just need a fast workflow now.

You can definitely write it.only and I believe you can do describe.only as well.

@iamrandys

This comment has been minimized.

Show comment
Hide comment
@iamrandys

iamrandys Aug 13, 2014

Karma does exactly what you are wanting and all you have to do is add a
karma.conf file to your project. I didn't realize karma supported reactify
and browserify. Now you can test in all of your browsers at the same time.
I created a PR for your boilerplate project.

https://github.com/iamrandys/react-component-boilerplate/tree/karma

Just run 'npm test' and karma will launch your browsers and will watch for
changes.

On Tue, Aug 12, 2014 at 10:35 AM, Tyrone Avnit notifications@github.com
wrote:

Thanks @iamrandys https://github.com/iamrandys. Developed a quick
react-component-boilerplate
https://github.com/TYRONEMICHAEL/react-component-boilerplate which uses
Mocha and Chai (Jasmine can be easily substituted). Tests are extremely
quick and you get the added benefit of Livereload. Use as you wish.


Reply to this email directly or view it on GitHub
#116 (comment).

Karma does exactly what you are wanting and all you have to do is add a
karma.conf file to your project. I didn't realize karma supported reactify
and browserify. Now you can test in all of your browsers at the same time.
I created a PR for your boilerplate project.

https://github.com/iamrandys/react-component-boilerplate/tree/karma

Just run 'npm test' and karma will launch your browsers and will watch for
changes.

On Tue, Aug 12, 2014 at 10:35 AM, Tyrone Avnit notifications@github.com
wrote:

Thanks @iamrandys https://github.com/iamrandys. Developed a quick
react-component-boilerplate
https://github.com/TYRONEMICHAEL/react-component-boilerplate which uses
Mocha and Chai (Jasmine can be easily substituted). Tests are extremely
quick and you get the added benefit of Livereload. Use as you wish.


Reply to this email directly or view it on GitHub
#116 (comment).

@sqs

This comment has been minimized.

Show comment
Hide comment
@sqs

sqs Aug 29, 2014

Use the following preprocessor.js to avoid JSX-transforming non-JSX files. As is, it only processes .jsx files that contain the /** @jsx prefix. If you want to JSX-transform .js files, just remove the first part of the if-condition before the || (so that only the src.slice ... condition remains).

// from http://facebook.github.io/jest/docs/tutorial-react.html
var ReactTools = require('react-tools');
var MAGIC = "/** @jsx";
module.exports = {
  process: function(src, file) {
    if (!/\.jsx$/.test(file) || src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

Still kinda slow, though.

sqs commented Aug 29, 2014

Use the following preprocessor.js to avoid JSX-transforming non-JSX files. As is, it only processes .jsx files that contain the /** @jsx prefix. If you want to JSX-transform .js files, just remove the first part of the if-condition before the || (so that only the src.slice ... condition remains).

// from http://facebook.github.io/jest/docs/tutorial-react.html
var ReactTools = require('react-tools');
var MAGIC = "/** @jsx";
module.exports = {
  process: function(src, file) {
    if (!/\.jsx$/.test(file) || src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

Still kinda slow, though.

@TYRONEMICHAEL

This comment has been minimized.

Show comment
Hide comment
@TYRONEMICHAEL

TYRONEMICHAEL Aug 29, 2014

Interesting snippet @sqs. Correct me If I am wrong, but would it still not have to look through the each file and check if it needs to convert it? I have had much success with the following - react-component-boilerplate. Tests actually run pretty quickly.

Interesting snippet @sqs. Correct me If I am wrong, but would it still not have to look through the each file and check if it needs to convert it? I have had much success with the following - react-component-boilerplate. Tests actually run pretty quickly.

@iamrandys

This comment has been minimized.

Show comment
Hide comment
@iamrandys

iamrandys Aug 29, 2014

Very nice. This reduced the time from 9.3s to 4.7s. This is for a single test. I'll still have to stay with Karma where it is much faster (100 tests take less than a second). Plus, Karma will watch for changes as you work and will test your code in multiple browsers, but I love Jest's automatic mocking though. Manually creating spies using rewireify is extra work, but you do have complete control.

Very nice. This reduced the time from 9.3s to 4.7s. This is for a single test. I'll still have to stay with Karma where it is much faster (100 tests take less than a second). Plus, Karma will watch for changes as you work and will test your code in multiple browsers, but I love Jest's automatic mocking though. Manually creating spies using rewireify is extra work, but you do have complete control.

@sqs

This comment has been minimized.

Show comment
Hide comment
@sqs

sqs Aug 29, 2014

Yeah, I may be misunderstanding you, but that's what I meant about removing the check for .jsx if you have .js files with jsx and want to detect based on the pragma header.

Sent from my iPhone

On Aug 28, 2014, at 23:45, Tyrone Avnit notifications@github.com wrote:

Interesting snippet @sqs. Correct me If I am wrong, but would it still not have to look through the each file and check if it needs to convert it? I have had much success with the following - react-component-boilerplate. Tests actually run pretty quickly.


Reply to this email directly or view it on GitHub.

sqs commented Aug 29, 2014

Yeah, I may be misunderstanding you, but that's what I meant about removing the check for .jsx if you have .js files with jsx and want to detect based on the pragma header.

Sent from my iPhone

On Aug 28, 2014, at 23:45, Tyrone Avnit notifications@github.com wrote:

Interesting snippet @sqs. Correct me If I am wrong, but would it still not have to look through the each file and check if it needs to convert it? I have had much success with the following - react-component-boilerplate. Tests actually run pretty quickly.


Reply to this email directly or view it on GitHub.

@amasad

This comment has been minimized.

Show comment
Hide comment
@amasad

amasad Sep 10, 2014

Contributor

Hi! I'm working on --watch for jest and generally trying to make this go faster. Will report back soon.

Contributor

amasad commented Sep 10, 2014

Hi! I'm working on --watch for jest and generally trying to make this go faster. Will report back soon.

@amasad amasad added the Enhancement label Sep 10, 2014

@aaronjensen

This comment has been minimized.

Show comment
Hide comment
@aaronjensen

aaronjensen Sep 21, 2014

Contributor

the first run for me takes about 5s (I just have one test, I'm just getting started). After that each additional run takes about 1.2-1.5s.

It looks like a decent amount of that time is spent loading the haste cache (which for my project is already a 4 meg file.

I'm looking forward to the --watch work, but I'm also wondering what is going on that requires 1.2 seconds of load time to run a test? I don't know anything about what haste is doing and why jest is using it, so I'm pretty clueless.

Contributor

aaronjensen commented Sep 21, 2014

the first run for me takes about 5s (I just have one test, I'm just getting started). After that each additional run takes about 1.2-1.5s.

It looks like a decent amount of that time is spent loading the haste cache (which for my project is already a 4 meg file.

I'm looking forward to the --watch work, but I'm also wondering what is going on that requires 1.2 seconds of load time to run a test? I don't know anything about what haste is doing and why jest is using it, so I'm pretty clueless.

@amasad

This comment has been minimized.

Show comment
Hide comment
@amasad

amasad Sep 21, 2014

Contributor

Haste supports a flavor of CommonJS module format were the module names are top-level rather than relative. That means we need to know the modules (and dependancies) ahead of time before running the program otherwise it would be incredibly inefficient to traverse the filesystem to look for a module on each require. However we realize that most people are using relative module format (a la node.js) and we want to remove the implicit dependency on Haste (unless an option is provided) and this should make it faster.

Contributor

amasad commented Sep 21, 2014

Haste supports a flavor of CommonJS module format were the module names are top-level rather than relative. That means we need to know the modules (and dependancies) ahead of time before running the program otherwise it would be incredibly inefficient to traverse the filesystem to look for a module on each require. However we realize that most people are using relative module format (a la node.js) and we want to remove the implicit dependency on Haste (unless an option is provided) and this should make it faster.

@aaronjensen

This comment has been minimized.

Show comment
Hide comment
@aaronjensen

aaronjensen Sep 22, 2014

Contributor

@amasad that sounds great. I've tried out intern.js and it runs a regular unit test from cmd line to finish in a few ms. Do you think jest could get to that fast? And have you considered extracting the automocking portion so that it is usable in other frameworks like jasmine or mocha?

Contributor

aaronjensen commented Sep 22, 2014

@amasad that sounds great. I've tried out intern.js and it runs a regular unit test from cmd line to finish in a few ms. Do you think jest could get to that fast? And have you considered extracting the automocking portion so that it is usable in other frameworks like jasmine or mocha?

@darcyadams

This comment has been minimized.

Show comment
Hide comment
@darcyadams

darcyadams Oct 30, 2014

I have found requiring files (especially 'react/addons' & the module being tested) once under the describe callback, instead of repeatedly in beforeEach or it callbacks makes a huge difference.

Obviously, I'm using coffee-script and not jsx, but this saves both preprocessor work and jest working to auto mock require calls.

__tests__/login_fields.coffee (3.013s) (ouch!)

describe 'Login Fields', -> 
 beforeEach ->
    {TestUtils} = require('react/addons').addons
    LoginFields = require '../login_fields'
    ...
  it 'should have left animation states defined', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should have a translateX value equal to enterStateStart.left', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call handleLogin on button click or enter press with the entered username and password', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call updateFields on all change events', ->
    {TestUtils} = require('react/addons').addons
    ...

but, it gets much faster with...
__tests__/login_fields.coffee (0.604s) (not bad)

describe 'Login Fields', ->
  {TestUtils} = require('react/addons').addons
  LoginFields = require '../login_fields'
  # require other repeatedly needed modules here as well

  beforeEach ->
    # now you can use TestUtils to renderIntoDocument LoginFields here

  it 'should have left animation states defined', ->
    # and use TestUtils here
  ...

I have found requiring files (especially 'react/addons' & the module being tested) once under the describe callback, instead of repeatedly in beforeEach or it callbacks makes a huge difference.

Obviously, I'm using coffee-script and not jsx, but this saves both preprocessor work and jest working to auto mock require calls.

__tests__/login_fields.coffee (3.013s) (ouch!)

describe 'Login Fields', -> 
 beforeEach ->
    {TestUtils} = require('react/addons').addons
    LoginFields = require '../login_fields'
    ...
  it 'should have left animation states defined', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should have a translateX value equal to enterStateStart.left', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call handleLogin on button click or enter press with the entered username and password', ->
    {TestUtils} = require('react/addons').addons
    ...
  it 'should call updateFields on all change events', ->
    {TestUtils} = require('react/addons').addons
    ...

but, it gets much faster with...
__tests__/login_fields.coffee (0.604s) (not bad)

describe 'Login Fields', ->
  {TestUtils} = require('react/addons').addons
  LoginFields = require '../login_fields'
  # require other repeatedly needed modules here as well

  beforeEach ->
    # now you can use TestUtils to renderIntoDocument LoginFields here

  it 'should have left animation states defined', ->
    # and use TestUtils here
  ...
@CodeOtter

This comment has been minimized.

Show comment
Hide comment
@CodeOtter

CodeOtter Nov 14, 2014

My tests are at 14 seconds long, even after using all of the optimizations recommended this far. Even with 16GB RAM and SSD. Jest is totally unusable in its current state. Sorry, switching to Karma.

My tests are at 14 seconds long, even after using all of the optimizations recommended this far. Even with 16GB RAM and SSD. Jest is totally unusable in its current state. Sorry, switching to Karma.

@iamrandys

This comment has been minimized.

Show comment
Hide comment
@iamrandys

iamrandys Nov 15, 2014

I've found great success with karma, mocha, chai, sinon, rewireify and aliasify. Over 300 tests run in 1/2 a second. Best of all React is AMAZING!!!!! The team LOVES it and have been developing some really good stuff with it. It's so clean and maintainable. Huge difference from anything we've ever used.

I've found great success with karma, mocha, chai, sinon, rewireify and aliasify. Over 300 tests run in 1/2 a second. Best of all React is AMAZING!!!!! The team LOVES it and have been developing some really good stuff with it. It's so clean and maintainable. Huge difference from anything we've ever used.

@kristoferjoseph

This comment has been minimized.

Show comment
Hide comment
@kristoferjoseph

kristoferjoseph Nov 18, 2014

Just ran into this myself. Tests run REALLY slow. Problem with slow tests is that developers disable them or only run them part of the time. Any idea what is causing this? How can I help?

Just ran into this myself. Tests run REALLY slow. Problem with slow tests is that developers disable them or only run them part of the time. Any idea what is causing this? How can I help?

@cortesi

This comment has been minimized.

Show comment
Hide comment
@cortesi

cortesi Nov 30, 2014

I had this exact issue - tests took about 17 seconds to run initially, and then 4 seconds after caching. It turns out that my build directory and external modules were not properly excluded. Setting the testPathDirs config option to point to the source directory reduced runtimes to 0.5 seconds.

cortesi commented Nov 30, 2014

I had this exact issue - tests took about 17 seconds to run initially, and then 4 seconds after caching. It turns out that my build directory and external modules were not properly excluded. Setting the testPathDirs config option to point to the source directory reduced runtimes to 0.5 seconds.

@ream88

This comment has been minimized.

Show comment
Hide comment
@ream88

ream88 Jan 6, 2015

This worked for me using React v0.12+:

var ReactTools = require('react-tools');


module.exports = {
  process: function(src, file) {
    if(!file.match(/\.react\.js$/)) return src;

    return ReactTools.transform(src);
  }
};

ream88 commented Jan 6, 2015

This worked for me using React v0.12+:

var ReactTools = require('react-tools');


module.exports = {
  process: function(src, file) {
    if(!file.match(/\.react\.js$/)) return src;

    return ReactTools.transform(src);
  }
};
@jprichardson

This comment has been minimized.

Show comment
Hide comment
@jprichardson

jprichardson Jan 7, 2015

Just started using Jest as well - just testing regular JavaScript modules (no JSX / React) and Jest is nasty slow. I love the idea of inline tests and built-in mocking, but it's so painfully slow it makes me miss Mocha. I'm not sure what the culprit is... it's not searching the directory tree that's causing the slow speed. If I specify the file directly, it's still super slow.

Any ideas on at least the cause of the slowness? (I'm not using JSX / CoffeeScript; auto-mocking is turned off)

Just started using Jest as well - just testing regular JavaScript modules (no JSX / React) and Jest is nasty slow. I love the idea of inline tests and built-in mocking, but it's so painfully slow it makes me miss Mocha. I'm not sure what the culprit is... it's not searching the directory tree that's causing the slow speed. If I specify the file directly, it's still super slow.

Any ideas on at least the cause of the slowness? (I'm not using JSX / CoffeeScript; auto-mocking is turned off)

@culshaw

This comment has been minimized.

Show comment
Hide comment
@culshaw

culshaw Jan 14, 2015

The original example never worked for me as the first argument always returned true.

var ReactTools = require('react-tools');
var MAGIC = "/** @jsx ";
module.exports = {
  process: function(src, file) {
    if (src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};

culshaw commented Jan 14, 2015

The original example never worked for me as the first argument always returned true.

var ReactTools = require('react-tools');
var MAGIC = "/** @jsx ";
module.exports = {
  process: function(src, file) {
    if (src.slice(0, MAGIC.length) != MAGIC) return src;
    return ReactTools.transform(src);
  }
};
@alvinsj

This comment has been minimized.

Show comment
Hide comment
@alvinsj

alvinsj Jan 21, 2015

@culshaw @Haihappen thanks for the nice workarounds, shorten the 10s+ tests to 2+. this workarounds made me think that maybe we should use the extension .jsx/.react.js for our react files, i think it might help too when using reactify.

alvinsj commented Jan 21, 2015

@culshaw @Haihappen thanks for the nice workarounds, shorten the 10s+ tests to 2+. this workarounds made me think that maybe we should use the extension .jsx/.react.js for our react files, i think it might help too when using reactify.

@culshaw

This comment has been minimized.

Show comment
Hide comment
@culshaw

culshaw Jan 21, 2015

To be honest going through Grunt I was still getting times of +20s, got
React working with Karma and total time is about +4/5 secs.

All inside a VM though

culshaw commented Jan 21, 2015

To be honest going through Grunt I was still getting times of +20s, got
React working with Karma and total time is about +4/5 secs.

All inside a VM though

@iamrandys

This comment has been minimized.

Show comment
Hide comment
@iamrandys

iamrandys Jan 22, 2015

Just to report back on this. We have been testing react with Karma/Mocha and we are close to 700 tests and it takes about 4 seconds to run all of the tests. We do have to mange mocks, but it's worth it. React has been AMAZING. Flawless and refreshingly stable. Game changer! Our team couldn't imaging using anything else.

Just to report back on this. We have been testing react with Karma/Mocha and we are close to 700 tests and it takes about 4 seconds to run all of the tests. We do have to mange mocks, but it's worth it. React has been AMAZING. Flawless and refreshingly stable. Game changer! Our team couldn't imaging using anything else.

@iamrandys

This comment has been minimized.

Show comment
Hide comment
@iamrandys

iamrandys Feb 5, 2015

I didn't ever get Jest to be fast. I am using mocha. If Jest was fast, I
would have used it instead.

On Thu, Feb 5, 2015 at 12:17 PM, Gil Birman notifications@github.com
wrote:

@iamrandys https://github.com/iamrandys would you mind explaining in
more detail how you managed to make jest so fast?


Reply to this email directly or view it on GitHub
#116 (comment).

I didn't ever get Jest to be fast. I am using mocha. If Jest was fast, I
would have used it instead.

On Thu, Feb 5, 2015 at 12:17 PM, Gil Birman notifications@github.com
wrote:

@iamrandys https://github.com/iamrandys would you mind explaining in
more detail how you managed to make jest so fast?


Reply to this email directly or view it on GitHub
#116 (comment).

@gilbox

This comment has been minimized.

Show comment
Hide comment
@gilbox

gilbox Feb 5, 2015

Thanks @iamrandys I had deleted my "how did you get jest to be fast?" question after realizing I had misread your post (but you responded at the same time)... anyway, it's a shame, I guess jest should still be considered not so ready for production use.

gilbox commented Feb 5, 2015

Thanks @iamrandys I had deleted my "how did you get jest to be fast?" question after realizing I had misread your post (but you responded at the same time)... anyway, it's a shame, I guess jest should still be considered not so ready for production use.

@adjavaherian

This comment has been minimized.

Show comment
Hide comment
@adjavaherian

adjavaherian Apr 23, 2015

If speed is still an issue, I suggest moving to Mocha. We have had a lot of success with this fork, which explains how to setup tests for simple to complex React deployments. https://github.com/adjavaherian/mocha-react We regularly run over a 100 tests in about 3 seconds.

If speed is still an issue, I suggest moving to Mocha. We have had a lot of success with this fork, which explains how to setup tests for simple to complex React deployments. https://github.com/adjavaherian/mocha-react We regularly run over a 100 tests in about 3 seconds.

@iamrandys

This comment has been minimized.

Show comment
Hide comment
@iamrandys

iamrandys Apr 24, 2015

I agree Mocha is the way to go. Up to almost 900 tests and it takes about 4 seconds.

On Apr 23, 2015, at 4:53 PM, Amir Djavaherian notifications@github.com wrote:

If speed is still an issue, I suggest moving to Mocha. We have had a lot of success with this fork, which explains how to setup tests for simple to complex React deployments. https://github.com/adjavaherian/mocha-react We regularly run over a 100 tests in about 3 seconds.


Reply to this email directly or view it on GitHub.

I agree Mocha is the way to go. Up to almost 900 tests and it takes about 4 seconds.

On Apr 23, 2015, at 4:53 PM, Amir Djavaherian notifications@github.com wrote:

If speed is still an issue, I suggest moving to Mocha. We have had a lot of success with this fork, which explains how to setup tests for simple to complex React deployments. https://github.com/adjavaherian/mocha-react We regularly run over a 100 tests in about 3 seconds.


Reply to this email directly or view it on GitHub.

@sporto

This comment has been minimized.

Show comment
Hide comment
@sporto

sporto Apr 26, 2015

Same experience, I just set up Jest with only one test (using JSX) and it takes about 3 seconds, this is a lot.

sporto commented Apr 26, 2015

Same experience, I just set up Jest with only one test (using JSX) and it takes about 3 seconds, this is a lot.

@ronag ronag referenced this issue in este/este May 4, 2015

Closed

Jest tests are slow #180

@kristian-puccio

This comment has been minimized.

Show comment
Hide comment
@kristian-puccio

kristian-puccio May 13, 2015

@iamrandys do you mind showing an example of your setup? Seems like the perfect combo.

@iamrandys do you mind showing an example of your setup? Seems like the perfect combo.

@songawee

This comment has been minimized.

Show comment
Hide comment
@songawee

songawee Jun 1, 2015

@amasad Is there an option with Jest to build up a cache for compiled files similar to what the babel-loader allows in the cacheDirectory option? - https://github.com/babel/babel-loader#options

songawee commented Jun 1, 2015

@amasad Is there an option with Jest to build up a cache for compiled files similar to what the babel-loader allows in the cacheDirectory option? - https://github.com/babel/babel-loader#options

@doodzik

This comment has been minimized.

Show comment
Hide comment
@doodzik

doodzik Jun 1, 2015

What makes jest slow for me isn't the compilation but rather the startup of the worker pool processes. All my test pass in under 0.05 seconds except the first ones, which take around 4 seconds.
https://github.com/jeffmo/node-worker-pool
https://github.com/facebook/jest/blob/master/src/TestRunner.js#L376

doodzik commented Jun 1, 2015

What makes jest slow for me isn't the compilation but rather the startup of the worker pool processes. All my test pass in under 0.05 seconds except the first ones, which take around 4 seconds.
https://github.com/jeffmo/node-worker-pool
https://github.com/facebook/jest/blob/master/src/TestRunner.js#L376

@amasad

This comment has been minimized.

Show comment
Hide comment
@amasad

amasad Jun 2, 2015

Contributor

@songawee It doesn't but want to send a PR to have it as an option? I don't think we should have it on by default because it's sometimes impossible to know when to break the cache. For example, if you change your compiler options, the cache should reset. Another option is to have a reset-cache option in addition to caching.

@doodzik are you sure it's the worker-pool and not the node-haste stating and reading of modules?

Contributor

amasad commented Jun 2, 2015

@songawee It doesn't but want to send a PR to have it as an option? I don't think we should have it on by default because it's sometimes impossible to know when to break the cache. For example, if you change your compiler options, the cache should reset. Another option is to have a reset-cache option in addition to caching.

@doodzik are you sure it's the worker-pool and not the node-haste stating and reading of modules?

@doodzik

This comment has been minimized.

Show comment
Hide comment
@doodzik

doodzik Jun 2, 2015

@amasad What I did was to measured the time each step in running jest took for completion.
And the node-worker-pool was the last instance where the tests were slow.
It could be that my findings are just the symptom and not the root of the problem.
But I hadn't had time to give it a proper analysis.

My tests currently look like this:
screen shot 2015-06-03 at 00 10 16

My react tests are slow(the ones in the examples folder). What I'm talking about are the non react tests.

doodzik commented Jun 2, 2015

@amasad What I did was to measured the time each step in running jest took for completion.
And the node-worker-pool was the last instance where the tests were slow.
It could be that my findings are just the symptom and not the root of the problem.
But I hadn't had time to give it a proper analysis.

My tests currently look like this:
screen shot 2015-06-03 at 00 10 16

My react tests are slow(the ones in the examples folder). What I'm talking about are the non react tests.

@craigdallimore craigdallimore referenced this issue in JedWatson/react-select Jun 15, 2015

Closed

Add Tests / Specs #240

cjk referenced this issue in este/este Jun 15, 2015

@screendriver

This comment has been minimized.

Show comment
Hide comment
@screendriver

screendriver Aug 12, 2015

Contributor

+1

Same here. Tests are very very slow 😞

Contributor

screendriver commented Aug 12, 2015

+1

Same here. Tests are very very slow 😞

@deerawan

This comment has been minimized.

Show comment
Hide comment
@deerawan

deerawan Aug 31, 2015

I thought It was only me that faced the issue. It is my first time using Jest and I don't get fast test result, either. Wondering how Facebook do the test using Jest?

I thought It was only me that faced the issue. It is my first time using Jest and I don't get fast test result, either. Wondering how Facebook do the test using Jest?

@alanrubin

This comment has been minimized.

Show comment
Hide comment
@alanrubin

alanrubin Aug 31, 2015

My question about Jest improvements to the React guys at React Europe conference Q&A session - https://youtu.be/CRJZBZ_-6hQ?t=363

My question about Jest improvements to the React guys at React Europe conference Q&A session - https://youtu.be/CRJZBZ_-6hQ?t=363

@gbbr

This comment has been minimized.

Show comment
Hide comment
@gbbr

gbbr Aug 31, 2015

Switched to Mocha + Sinon. Never been happier.

On 31 August 2015 at 17:45, Alan Rubin notifications@github.com wrote:

My question about Jest to the React guys at React Europe conference Q&A
session - https://youtu.be/CRJZBZ_-6hQ?t=363


Reply to this email directly or view it on GitHub
#116 (comment).

gbbr commented Aug 31, 2015

Switched to Mocha + Sinon. Never been happier.

On 31 August 2015 at 17:45, Alan Rubin notifications@github.com wrote:

My question about Jest to the React guys at React Europe conference Q&A
session - https://youtu.be/CRJZBZ_-6hQ?t=363


Reply to this email directly or view it on GitHub
#116 (comment).

@hansman

This comment has been minimized.

Show comment
Hide comment
@hansman

hansman Sep 15, 2015

I have the same problem. Jest tests just take a lot of time and the execution time actually varies. Whether to run them in parallel or in just one process (--runInBand) did not matter. It appears to not be a resource contention between the worker processes.

I created some cpu dumps with the v8 profiler (https://github.com/node-inspector/v8-profiler) and found that most time appears to be spent mocking modules. I.e. 25% of the execution time of my unit test is spent in jest-cli/src/lib/utils.js#runContentWithLocalBindings.

hansman commented Sep 15, 2015

I have the same problem. Jest tests just take a lot of time and the execution time actually varies. Whether to run them in parallel or in just one process (--runInBand) did not matter. It appears to not be a resource contention between the worker processes.

I created some cpu dumps with the v8 profiler (https://github.com/node-inspector/v8-profiler) and found that most time appears to be spent mocking modules. I.e. 25% of the execution time of my unit test is spent in jest-cli/src/lib/utils.js#runContentWithLocalBindings.

@cdreier

This comment has been minimized.

Show comment
Hide comment
@cdreier

cdreier Oct 5, 2015

Contributor

any performance updates? just picked up jest with es6 and babel-jest, but running 2 simple tests in > 10 seconds :-(
tried a lot of ideas from this thread to speed up, but nothing worked...

Contributor

cdreier commented Oct 5, 2015

any performance updates? just picked up jest with es6 and babel-jest, but running 2 simple tests in > 10 seconds :-(
tried a lot of ideas from this thread to speed up, but nothing worked...

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Oct 5, 2015

Contributor

We'll be focusing on this soon. We are a little swamped with work on jest right now but we are committed to make it more awesome.

Contributor

cpojer commented Oct 5, 2015

We'll be focusing on this soon. We are a little swamped with work on jest right now but we are committed to make it more awesome.

@clentfort

This comment has been minimized.

Show comment
Hide comment
@clentfort

clentfort Oct 5, 2015

Contributor

Are there any tasks the community could help with?

Contributor

clentfort commented Oct 5, 2015

Are there any tasks the community could help with?

@hansman

This comment has been minimized.

Show comment
Hide comment

hansman commented Oct 5, 2015

+1

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Oct 5, 2015

Contributor

The biggest help right now would actually be improving the documentation, website and going through issues and helping out people in open source.

Contributor

cpojer commented Oct 5, 2015

The biggest help right now would actually be improving the documentation, website and going through issues and helping out people in open source.

@hansman

This comment has been minimized.

Show comment
Hide comment
@hansman

hansman Oct 5, 2015

One thing we have done to speed our JEST tests up in the build pipeline was to replace our single core machine with a multi core one. By default jest spawns as many workers as hardware threads are available. If this is not available to you you can manually play with '-w' (maxWorkers). You may gain a speedup also on a single core.

Ultimately we found that mocking modules is very costly (see my comment above) and causes a majority of the execution time.

hansman commented Oct 5, 2015

One thing we have done to speed our JEST tests up in the build pipeline was to replace our single core machine with a multi core one. By default jest spawns as many workers as hardware threads are available. If this is not available to you you can manually play with '-w' (maxWorkers). You may gain a speedup also on a single core.

Ultimately we found that mocking modules is very costly (see my comment above) and causes a majority of the execution time.

@fabiosussetto

This comment has been minimized.

Show comment
Hide comment
@fabiosussetto

fabiosussetto Oct 15, 2015

Jest with es6 for me is completely unusable. it takes 10+ seconds just to start up, and then it takes 2s to run the single test I have at the moment. I was expecting a lot more, switching back to karma :(

Jest with es6 for me is completely unusable. it takes 10+ seconds just to start up, and then it takes 2s to run the single test I have at the moment. I was expecting a lot more, switching back to karma :(

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Oct 16, 2015

Contributor

We are currently working on replacing node-haste with a new module resolver, which should fix this issue.

Contributor

cpojer commented Oct 16, 2015

We are currently working on replacing node-haste with a new module resolver, which should fix this issue.

@HenriJ

This comment has been minimized.

Show comment
Hide comment
@HenriJ

HenriJ Dec 3, 2015

Hi all. Is there any news on this issue ?

HenriJ commented Dec 3, 2015

Hi all. Is there any news on this issue ?

@QuantumInformation

This comment has been minimized.

Show comment
Hide comment
@QuantumInformation

QuantumInformation Dec 14, 2015

Hi, is Jest suitable for non React testing? Would like to have a common standard for both react and non-react apps in our team.

Hi, is Jest suitable for non React testing? Would like to have a common standard for both react and non-react apps in our team.

@clentfort

This comment has been minimized.

Show comment
Hide comment
@clentfort

clentfort Dec 14, 2015

Contributor

Jest is a universal test-runner and you are in no way required to use React. :) Just take a look at one of the examples!

Contributor

clentfort commented Dec 14, 2015

Jest is a universal test-runner and you are in no way required to use React. :) Just take a look at one of the examples!

@SomniumDigital

This comment has been minimized.

Show comment
Hide comment
@SomniumDigital

SomniumDigital Jan 7, 2016

Hi all, some real interesting info on here. I'm also experiencing issues with tests running slow too. I've currently got 13 tests taking ~15secs to run.

I did find adding "testPathDirs": ["<rootDir>/path/to/tests/"] to our packages.json file helped to improve the startup time considerably.

@cpojer Have you got an update for us regarding the new and improved module resolver? I'm really hoping that this is going to be the key to getting tests running much quicker

Hi all, some real interesting info on here. I'm also experiencing issues with tests running slow too. I've currently got 13 tests taking ~15secs to run.

I did find adding "testPathDirs": ["<rootDir>/path/to/tests/"] to our packages.json file helped to improve the startup time considerably.

@cpojer Have you got an update for us regarding the new and improved module resolver? I'm really hoping that this is going to be the key to getting tests running much quicker

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Jan 7, 2016

Contributor

This work is happening in #599.

Contributor

cpojer commented Jan 7, 2016

This work is happening in #599.

@SomniumDigital

This comment has been minimized.

Show comment
Hide comment
@SomniumDigital

SomniumDigital Jan 7, 2016

Thanks @cpojer 😀
I look forward to seeing the finished Haste2

Thanks @cpojer 😀
I look forward to seeing the finished Haste2

@srossross

This comment has been minimized.

Show comment
Hide comment
@srossross

srossross Feb 16, 2016

The same tests using mocha run in 44ms for me where jest took full 6 seconds.

It took me about 15 minutes to switch my initial 6 test files using jest to using Mocha, jsdom and sinon.

The same tests using mocha run in 44ms for me where jest took full 6 seconds.

It took me about 15 minutes to switch my initial 6 test files using jest to using Mocha, jsdom and sinon.

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Feb 16, 2016

Contributor

Good news everyone, I'm merging #599 today and it should do away with the slow startup, finally.

Contributor

cpojer commented Feb 16, 2016

Good news everyone, I'm merging #599 today and it should do away with the slow startup, finally.

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Feb 17, 2016

Contributor

Ok, this should finally be fixed in Jest 0.9. Sorry that this took so long but there was some clowniness in Jest :)

See facebook/react#6052 on how the React tests themselves were sped up. If you'd like to try this improvement, check out the comments in #599. It is currently tagged as jest-cli@next until to see if there are any bugs that people in open source might encounter. I'll close this issue as resolved.

Contributor

cpojer commented Feb 17, 2016

Ok, this should finally be fixed in Jest 0.9. Sorry that this took so long but there was some clowniness in Jest :)

See facebook/react#6052 on how the React tests themselves were sped up. If you'd like to try this improvement, check out the comments in #599. It is currently tagged as jest-cli@next until to see if there are any bugs that people in open source might encounter. I'll close this issue as resolved.

@cpojer cpojer closed this Feb 17, 2016

@SomniumDigital

This comment has been minimized.

Show comment
Hide comment
@SomniumDigital

SomniumDigital Feb 17, 2016

npm install jest-cli@next if you want to run this new version (rather than jest@next @cpojer)

npm install jest-cli@next if you want to run this new version (rather than jest@next @cpojer)

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Feb 17, 2016

Contributor

oh yeah, I always make this mistake :) I edited my original comment.

Contributor

cpojer commented Feb 17, 2016

oh yeah, I always make this mistake :) I edited my original comment.

@steinbachr

This comment has been minimized.

Show comment
Hide comment
@steinbachr

steinbachr Feb 24, 2016

@cpojer after upgrading using npm install jest-cli@next I'm having problems specifying dontMock. By which I mean, before the update (using jest@0.8.2) this line works properly:

jest.dontMock('../../../../fixtures');

then after the update to 0.9.0, the same call results in the module being mocked

@cpojer after upgrading using npm install jest-cli@next I'm having problems specifying dontMock. By which I mean, before the update (using jest@0.8.2) this line works properly:

jest.dontMock('../../../../fixtures');

then after the update to 0.9.0, the same call results in the module being mocked

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Feb 24, 2016

Contributor

@steinbachr that should probably go into a separate issue. Would be great if you could provide a repro, haven't seen this issue come up at FB!

Contributor

cpojer commented Feb 24, 2016

@steinbachr that should probably go into a separate issue. Would be great if you could provide a repro, haven't seen this issue come up at FB!

@steinbachr

This comment has been minimized.

Show comment
Hide comment
@steinbachr

steinbachr Feb 24, 2016

thanks @cpojer, issue created here

thanks @cpojer, issue created here

@rubystar rubystar referenced this issue in verekia/js-stack-from-scratch Feb 2, 2017

Closed

RFC: Favor npm scripts instead of gulp #132

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment