Jest – Painless JavaScript Testing(facebook.github.io)
facebook.github.io
Jest – Painless JavaScript Testing
http://facebook.github.io/jest/index.html
12 comments
Shorter feedback loop is always great. Running tests in parallel is a non-brainer.
Leveraging Jasmine is great too. Glad to see it's not reinventing the wheel!
Here's another interesting part, on dependency injection: http://facebook.github.io/jest/docs/common-js-testing.html#c...
Leveraging Jasmine is great too. Glad to see it's not reinventing the wheel!
Here's another interesting part, on dependency injection: http://facebook.github.io/jest/docs/common-js-testing.html#c...
I would've built Jest on top of Mocha. It's a slightly better testing framework, especially when it comes to async tests.
At some point I'd like to add support for using mocha within Jest as well.
Right now we use jasmine internally, so I was pretty focused on getting it running with that. However, it is (quite intentionally) built such that the 'jasmine' parts are pretty isolated similar to a plug-in; So it should be possible to build plug-ins for other frameworks like Mocha as well at some point.
Right now we use jasmine internally, so I was pretty focused on getting it running with that. However, it is (quite intentionally) built such that the 'jasmine' parts are pretty isolated similar to a plug-in; So it should be possible to build plug-ins for other frameworks like Mocha as well at some point.
Mock functions are a really powerful tool. They let you test asynchronous functions in an entirely synchronous way. Because of that, Jest doesn't need to provide special support for asynchronous testing
http://facebook.github.io/jest/docs/tutorial.html#content
http://facebook.github.io/jest/docs/tutorial.html#content
That might work for simple cases but I'd be worried that switching all your asynchronous calls to synchronous has the potential to introduce bugs that your tests would then miss. Testing asynchronous functions is hard for lots of reasons, and only one of them is that you have to wait for it to finish.
It's great that they're improving an existing/familiar tool like Jasmine.
Also, I love the way they treat CommonJS modules.
Sorry for the dumb question, but as a JS (and JS testing) newbie, could someone explain how Jest is different from Jasmine (from which it's built on) or, say, from Mocha?
Jasmine provides you with the testing primitives such as describe(), it(), expect(value).toEqual(other): http://facebook.github.io/jest/docs/api.html#globally-inject...
Jest adds multiple layers on-top:
- A mock library (also called stubs) in order to create fake functions and assert that they are called as you want: http://facebook.github.io/jest/docs/mock-functions.html#cont...
- A way to provide an alternate implementation for dependencies using require(): http://facebook.github.io/jest/docs/common-js-testing.html#c...
- It inspects the shape of your dependencies and return a mocked version of them: http://facebook.github.io/jest/docs/automatic-mocking.html#c...
- Finally, it works in node instead of the browser and uses jsdom to let you test code related to the DOM. (It also runs tests in parallel)
Jest adds multiple layers on-top:
- A mock library (also called stubs) in order to create fake functions and assert that they are called as you want: http://facebook.github.io/jest/docs/mock-functions.html#cont...
- A way to provide an alternate implementation for dependencies using require(): http://facebook.github.io/jest/docs/common-js-testing.html#c...
- It inspects the shape of your dependencies and return a mocked version of them: http://facebook.github.io/jest/docs/automatic-mocking.html#c...
- Finally, it works in node instead of the browser and uses jsdom to let you test code related to the DOM. (It also runs tests in parallel)
Can someone copy/paste this into the docs? :) It was really helpful, thanks.
I went ahead and added it to the main page of the website:
http://facebook.github.io/jest/
http://facebook.github.io/jest/
jinx!
Many thanks! (to both of you ;)
jasmine and mocha are test frameworks (they're the things that supply your describe() and it() functions), but they don't really supply you with everything you need to get set up to run tests.
jest is a test runner that includes a few additional things to try to make all aspects of writing and running tests a little easier...such as:
* Searches for tests to find + execute so that you can put tests near the modules they are testing
* Runs tests in parallel processes so that your test runs finish sooner
* Replace's node's built-in require() function with a custom one that acts almost entirely the same -- except (by default) it returns mocked versions of modules (rather than the real things) when your tests run
* Gives you a fake DOM implementation (using jsdom) so that you can test code that depends on DOM APIs on the command line without having to boot up a browser
jest is a test runner that includes a few additional things to try to make all aspects of writing and running tests a little easier...such as:
* Searches for tests to find + execute so that you can put tests near the modules they are testing
* Runs tests in parallel processes so that your test runs finish sooner
* Replace's node's built-in require() function with a custom one that acts almost entirely the same -- except (by default) it returns mocked versions of modules (rather than the real things) when your tests run
* Gives you a fake DOM implementation (using jsdom) so that you can test code that depends on DOM APIs on the command line without having to boot up a browser
Nice. When will there be a grunt plugin for it? I'm using the qunit plugin right now and I notice that it's 10x slower to run than viewing it in the browser. This 10 second feedback loop is driving me crazy.
About a month or three ago I hacked up a grunt task for React, but it wasn't very useful since we hadn't opensourced Jest yet.
The code is now a little stale and dated, but it basically just shells out to the bin/jest.js script included with Jest. Turned out no more than a ~30lines:
https://github.com/jeffmo/react/commit/7a72cbba0eb57844f4e22...
The code is now a little stale and dated, but it basically just shells out to the bin/jest.js script included with Jest. Turned out no more than a ~30lines:
https://github.com/jeffmo/react/commit/7a72cbba0eb57844f4e22...
Rule number one of Grunt: "If you can npm it, you soon will be able to Grunt it(or Gulp it for that matter)"
Fantastic. Great answer and now much clearer to me. Thanks! (both of you ;)
BTW, I've updated the main page of the site to give some more context here -- thanks for asking the question!
This looks cool. Manual mocking has always been, if not a pain, a major annoyance.
On a side note, I got a good chuckle from the "Bobby Tables" XKCD reference[1] in the Jest tutorial[2].
[1]: http://xkcd.com/327/ [2]: http://facebook.github.io/jest/docs/tutorial.html
On a side note, I got a good chuckle from the "Bobby Tables" XKCD reference[1] in the Jest tutorial[2].
[1]: http://xkcd.com/327/ [2]: http://facebook.github.io/jest/docs/tutorial.html
Wish all it was was a mocking library... w/o the testing built in.
That way you could use it easily with Mocha (and should, etc).
That way you could use it easily with Mocha (and should, etc).
(Hi, I'm the fb eng who wrote Jest)
Yea, I'd really like to add support for other testing frameworks as well.
Right now we use jasmine internally, so I was pretty focused on getting it running with that. However, it is (quite intentionally) built such that the 'jasmine' parts are pretty isolated similar to a plug-in; So it should be possible to build plug-ins for other frameworks as well (like Mocha, QUnit, etc) in the future.
Yea, I'd really like to add support for other testing frameworks as well.
Right now we use jasmine internally, so I was pretty focused on getting it running with that. However, it is (quite intentionally) built such that the 'jasmine' parts are pretty isolated similar to a plug-in; So it should be possible to build plug-ins for other frameworks as well (like Mocha, QUnit, etc) in the future.
You might want to look at http://www.venusjs.org/ to get some ideas for supporting multiple testing frameworks. It uses an annotation approach kind of how you include files for tests. The automatic mocking is pretty awesome though.
This looks really neat, having to re-specify the interface of the collaborators is generally a bunch of boilerplate you don't want to need!
Did you consider building on top of Sinon.JS and only having jest do the require/detect/build-mock part? Your mock API seems very similar.
Did you consider building on top of Sinon.JS and only having jest do the require/detect/build-mock part? Your mock API seems very similar.
I hadn't looked at Sinon.JS before, but it does seem worth checking into...thanks!
Any plans to support AMD or just commonjs?
You can use this https://github.com/Jakobo/redefine
this is awesome. thank you for your work.
I use sinon (function mocking) and proxyquire (mock requires) for mocking with mocha and they work well.
Have you looked at JsMockito?
Wow, Facebook has been rocking the house lately with their JS contributions. Great work and thank you!
Might be a silly question, but has anyone tried Jest along with AngularJS and survived to tell the story? Mocking stuff has always been one of my biggest pain points when testing on Angular and I'm really itching to try this! Congrats folks at Facebook.
Agreed on that count. Have you come up with any good solutions for angular? I always feel like my tests end up with too much boilerplate.
Explain me how mocking is difficult with Angular? when Angular has a mocking framework.
Where did I say "difficult"? I said "pain point", which is different. In my experience, same as your sibling comment, you end up having a lot of boilerplate and it's just convoluted. Mocking out stuff should be simpler, in my opinion. How about auto-generating Jasmine spies, for example?
Resharper added jasmine support in v.7 as far as I remember. I wonder if Jest would work with Resharper out of the box, would be helpful in .NET world to have the Jest runner integrated with VS.
Looks interesting: the test suite for our current AngularJS project is slowly slowing down, in part because there's just more tests, but the major performance bottlenecks are:
* No parallelisation, even if test suites are all independent * DOM tests, which cause a lot of GC pauses * (probably) PhantomJS startup and initialisation (not measured)
I've done a simple optimization where my tests get split in the middle and run in two separate terminals (during development, continuous testing), but it's kinda iffy.
* No parallelisation, even if test suites are all independent * DOM tests, which cause a lot of GC pauses * (probably) PhantomJS startup and initialisation (not measured)
I've done a simple optimization where my tests get split in the middle and run in two separate terminals (during development, continuous testing), but it's kinda iffy.
I wonder if they are using CoffeeScript anywhere at Facebook?
http://facebook.github.io/jest/docs/tutorial-coffeescript.ht...
http://facebook.github.io/jest/docs/tutorial-coffeescript.ht...
We're not using CoffeeScript inside of Facebook. But we are using many ES6 features that make JS look a lot like CoffeeScript such as classes, arrow functions, rest arguments, destructuring assignment ... I figured that CoffeeScript would be a good example to show that Jest supports languages that transpile to JS :)
Curious - What are you using to transpile your ES6? Traceur?
Internally we use jstransform (github.com/facebook/jstransform) because it allows us to plug in individual transforms more easily. It's also what React uses for it's jsx transformations.
jstransform also ships with a few es6 features out of the box (classes, arrow functions, etc -- and the number is growing!), but Traceur definitely has more.
jstransform also ships with a few es6 features out of the box (classes, arrow functions, etc -- and the number is growing!), but Traceur definitely has more.
Actually our recent shortcuts-for-framer project happens to use CoffeeScript, but this is very much an outlier. https://github.com/facebook/shortcuts-for-framer
[deleted]
I think auto mocking modules is the most horrible trick a testing framework can pull.
So because you're too lazy to write modules with a minimum of sane dependency injection,you hack require (which is not dependency injection) to mock dependencies?
This is actually the most awfull anti pattern i've seen in javascript land yet.Unfortunatly, it's becoming the "way to go" for most developpers. Instead of making your modules pluggable and decoupled,you negates everything testing is for,you just dont write testable code.
So because you're too lazy to write modules with a minimum of sane dependency injection,you hack require (which is not dependency injection) to mock dependencies?
This is actually the most awfull anti pattern i've seen in javascript land yet.Unfortunatly, it's becoming the "way to go" for most developpers. Instead of making your modules pluggable and decoupled,you negates everything testing is for,you just dont write testable code.
This isn't so bad. Before DI got popular in PHP via Symfony2, we used Zend_Registry. "require" is pretty much the same thing in this context.
what is the effective difference between mocking an injected dependency and a located one?
Is it just me, or does having the background tinted red make you anxious too?
I toned it down a little bit -- hope that helps. :)
What it really needs is a GIF of Harley Quinn dancing in the background.
(This is a joke. Please don't do it.)
(This is a joke. Please don't do it.)
Yeah it does. Thanks
Congrats guys. :)