7 ms·

Jest – Painless JavaScript Testing

202 points by huan9huan 10y ago

misiti3780 10y ago
I have used jest and i have used mocha. I use mocha because I got sick of having to "unmock" everything in jest tests. People have complained that jest is slow, that was never a problem I encountered. The unmock becomes very annoying after a while.
- andyeskridge 10y ago
  Jest has changed a lot lately. Back in September they changed the mocking to be opt-in. [1] The speed is also very much improved! [1] http://facebook.github.io/jest/blog/2016/09/01/jest-15.html#disabled-automocking http://facebook.github.io/jest/blog/2016/09/01/jest-15.html#...
- wwalser 10y ago
  I always used the option to turn it off by default. What you're left with (instead of having to unmock loads of stuff) is a parallel test runner with and a utility that is capable of mocking most anything upon command. They recently changed mocking to be opt-in.
- Lazare 10y ago
  When jest was first released, it was incredibly, glacially slow, buggy, poorly documented, and seemed to be largely unmaintained. Critical features were broken and stayed broken for months. I was an early adopter and I got burned hard, having to rewrite everything in Mocha. Since then, apparently, it has changed hugely, and is now fast, reliable, and pleasant to use. Or so I've heard; I have no particular reason to change back to jest, since mocha is fine. But if you're wondering why you've heard about it being slow, it's because for many, many months jest was absurdly, unbelievably slow; simple "hello world" tests would take seconds, and even a medium projects would take minutes. And there was no watch mode, nor any ability to re-run failing tests, or re-run tests on changed files. It was absurd. Edit: See, eg, https://github.com/facebook/jest/issues/116 https://github.com/facebook/jest/issues/116 opened 8 Aug 2014, and finally closed 17 Feb 2016. Quite a run. Also, there were tons of bugs with the mocking and, especially, the `dontMock()` methods; many things could cause attempts to turn mocking off to silently, invisibly fail (or even more fun, to cause an attempt to disable mocking on one item to cause it to be silently, invisibly disabled on all items). It's amazingly hard to track down a failing test when a bug triggered by code in another test can cause items that should be mocked to not be mocked, and visa versa.
haney 10y ago
I've been working on a React Native project and I really enjoy how easy jest is to use. It's hard to tell from this post though, is there something new/specific about it? Or are we all just agreeing that it's awesome?
wwalser 10y ago
I have a strange history with JS test libraries. Of the 4 that I've used, I've fixed bugs in 3 of them within a week of first picking it up. QUnit, Sinon and Jest. This isn't commentary on the quality of Jest. After turning off auto-mocking and instead only using the mocking when I really needed it, I ended up using it for a moderately successful side project and enjoyed the experience.
- andrewstuart2 10y ago
  Have you used jasmine + karma? That's been, and still is, my go-to for solid and fast testing.
  - dancek 10y ago
    It's solid once you get everything set up, but that takes me a while. Of course I've only set it up for a couple of projects, using different build systems, and having tried other test libraries in between in order to minimize the chances of my remembering anything... I think there's room for one or two test frameworks that Just Work. Surely you'll lose some configurability, but mostly you don't need it.
  - wwalser 10y ago
    I have used Jasmine+Karma. It's good stuff. It doesn't have the the "awesome stuff baked in" feel that Jest gives but it also doesn't give you a headache when something baked in doesn't work as expected :).
- mambodog 10y ago
  Automocking is off by default now, and a lot of work has been done to improve the developer experience in recent times.
  - wwalser 10y ago
    Thanks for the work you & the team have put into Jest. While I haven't used it recently, I'm glad that it's out there as an option. The _ability_ to mock easily was always super great.
Nitramp 10y ago
This doesn't do browser testing (like Karma), it's just an alternative to mocha, right?
- b34r 10y ago
  Not out of the box, but the environment setup is easily configurable. I've been using a Protractor for my E2E tests since it also uses Jasmine... does the trick until there is more first-party support.
- BJanecke 10y ago
  It comes with jsDom baked into it for browser behaviour. Using a full headless browser to test with is not ideal, however I trust that you have a good reason to want that. If that is a requirement for you, you can tie jest up to karma :), but I beseech you to have a very good reason to test against a headless browser first :)
  - Nitramp 10y ago
    Depends on what you want to test, I guess. If you want to test UI widget behaviour (not just business logic), then jsDom probably isn't the right tool and you need a browser. E.g. if you need CSS measurements or more tricky DOM behaviour. It's not entirely clear to me why you'd want a headless browser though. Once you're already running a browser, you might as well run a full one, and also get the debugging capabilities.
batmansmk 10y ago
The last versions are for us better than the other tool. The snapshot feature is pretty neat.
rileyt 10y ago
Jest used to have a lot of problems and was poorly maintained. Over the past few months, that has changed entirely. Improved speed, lots of bug fixes, snapshot tests and general ease of setup with React projects have all really helped. Jest is now the test framework I would suggest for anyone starting a new React project.
- mullsork 10y ago
  Agreed. We started using Jest in April 2015 or so and I hated it with a passion for well over a year. I can't remember exactly which version it was but it go improved by miles recently. Now my goto JS test library without a doubt.
- endisukaj 10y ago
  Has the documentation improved? Last time I checked it (about a year or so ago) it was terrible.
  - shaneos 10y ago
    It's but a click away (and yes it has :-)) http://facebook.github.io/jest/docs/getting-started.html http://facebook.github.io/jest/docs/getting-started.html
  - lacker 10y ago
    We've improved it some but there's more to go. If you have specific parts that you consider to be still-terrible let us know!
- k__ 10y ago
  Seems like it was a side project of some FB employees and it didn't get traction till a few months ago. Till then the project pretty much stalled.
wildpeaks 10y ago
Jest sounds good on paper, it's great it exists and it definitely has potential and even improved a lot recently (and I usually try every new version that come up), however I have two pain points with it that prevent me from switching to Jest for now: - it uses regexes instead of globs, so you can't just give it the list of tests like you would with Mocha or electron-mocha (e.g. something like "jest src/* * /*.tests.js") - it excludes paths that include "node_modules" and it's not just a default (which would be fine), it's hardcoded, so you can forget about local modules, or dependencies that use local modules Fortunately, there are already open issues for both, so that might improve in the future :) --- Edit: I had to add extra spaces in the glob example (so it's slightly incorrect) because HN formatting seems to prevent using "double star".
- b34r 10y ago
  Hey there, frequent Jest contributor here! Globs are under consideration (there's an issue from a collaborator on the subject.) FWIW, Jest is insanely good. I've been using it for almost 2 years now through some of the rougher patches in its development and man, it's an extremely well thought-out system with a team of highly motivated maintainers. Facebook uses it for almost all their JS projects, so it gets a LOT of attention and TLC. Many things that were poor defaults have been changed since v17, like getting rid of auto mocking. It's worth a look again.
- cpojer 10y ago
  I work on Jest at FB. * I agree regexes suck but that's all we had five years ago when it was started. Would love to move to a glob system incrementally but most of that will have to come from the community. I'm also still concerned about performance. We match things against tens of thousands of files a lot and regex seems strictly faster to me but I'm happy to be proven wrong or shown that it won't be relevant. * There is one minor issue with create-react-app's recommended use of node_modules to split up things. I would recommend lerna for multi-package development ( https://github.com/lerna/lerna https://github.com/lerna/lerna ) and we are hoping to put whatever fix in place here that will work well. There are workarounds but they aren't great.
  - 10y ago
efrafa 10y ago
Are you forced to use expect().to... or you can plugin any assert library ? (I get the benefits of expect but I still prefer assert style)
- ville 10y ago
  You can use any assertion library and it will just work. At one point I was using Jest with Chai when migrating a codebase that happened to use Chai for assertions.
jcoffland 10y ago
There's no such thing as painless testing.
- gotofritz 10y ago
  If it ain't hurting, you ain't doing it right.
- onion2k 10y ago
  Maintaining disorganised code hurts a lot more than writing tests.
- rpastuszak 10y ago
  But it hurts so good. As opposed to the alternative, which is dealing with technical dept, spaghetti, legacy code, etc...
  - amelius 10y ago
    Testing and technical debt/spaghetti code/legacy code are not mutually exclusive.
    - shados 10y ago
      you're right. But testing bad code is really really hard. So usually tested code is somewhat better overall, just because it's the easiest way to do it.
- blauditore 10y ago
  If you develop the tests along with the main code, it's usually less painful, except if there's a hunk of legacy code to integrate your new one with. Ok, this is probably the case for most developers...
petetnt 10y ago
Jest has taken great steps forward in the oast year and I see the momentum only going up. Kudos to the whole team!
aikah 10y ago
Still sticking to Jasmine. Simple and efficient and no need for nodejs to run tests.
orta 10y ago
I'm a big fan of Jest - if you're using Jest with Visual Studios Code, I'd recommend looking at my extension that gives you a mode IDE-like experience. https://github.com/orta/vscode-jest https://github.com/orta/vscode-jest
- BJanecke 10y ago
  That's pretty darned rad! Kinda like wallabyjs, but not hitting me over the head with a license :P
- shados 10y ago
  Tried it for the first time yesterday. It is pretty amazing and the productivity boost is crazy (it's one of those tools that changes the balance when you ask if testing is worth the time or not).
- badthingfactory 10y ago
  Thank you for this! I've been patiently waiting for someone more motivated and intelligent than myself to create a free inline test runner. You are my hero. Keep the project open source, free, and plop a donations button on the page and I'll be quick to open my wallet.
kybernetikos 10y ago
Snapshot testing overconstrains your tests, and encourages people who see tests breaking just to rerun the snapshot without thinking too much. The painlessness comes with a cost.
- cpojer 10y ago
  Hi! I work on JavaScript Tools at FB. There is a fantastic post by Ben McCormick about the up and downsides of this system: http://benmccormick.org/2016/09/19/testing-with-jest-snapshots-first-impressions/ http://benmccormick.org/2016/09/19/testing-with-jest-snapsho... Snapshots aren't the only feature of Jest; it is simply one assertion in our assertion library. There is a ton of other stuff in the framework that makes setting up a test environment and writing tests easier. My philosophy for building a test framework is to build a good feature set to help you out in any situation but the user should be in total control. This allows you to find the best way to test your code which I've found to be extremely subjective. The choice of test framework and test methodology seems almost religious at times and I've deliberately tried to stay away from these conversations.
  - kybernetikos 10y ago
    Indeed, I'm not criticising Jest which most of our developers really like, merely criticising snapshot testing, which is one of the ways we are using jest. The Ben McCormick post does cover some of the issues with snapshot testing, particularly around lack of communication of developer intent. If you wrote a unit test that asserted that a tree of data looked exactly a particular way, when the only correctness/incorrectness criteria was whether or not a particular prop was present on one of the branches, then you've written a bad test. Using a snapshot means that your test fails when your code changes in ways that are still correct. It's a test that invites lots of false negatives, and the reason that is considered acceptable is because it makes it easy to update the test when it predictably gives you the false negative. Normally writing tests that depend on the exact implementation details of the code under test is considered a bad thing. I can't help but think that there are better solutions to this problem. Almost immediately after one of our teams started using snapshot testing, we had test breakages because an entirely different component that we used in an ancillary way had a semver minor change (added a new prop that was defaulted) and that broke tests (but not the app) in our component. Perhaps we're doing it wrong, but adding tests to packages that can trivially be incorrectly broken by your dependencies changing is fairly painful (and makes a mockery of semver).
krrkrrmjao 10y ago
do we really need MORE testing frameworks? the devs should join jasmine instead
spraak 10y ago
Two questions: 1. What good books (or repos) that use JS can you recommend for writing good tests? 2. What advantages does Jest have over Jasmine?
- aj0strow 10y ago
  RE: 2. Jest bundles Jasmine. It's primarily a test runner (like karma[1]) more than a framework. Jest includes mocking capabilities at the function level (like sinon[2]) and module level (like rewire[3]). It supports parallel execution, custom source code transpiling, file extension mocks (for webpack requires) and file watching. It favors large ES6 projects -- takes a second to start up. [1]: https://github.com/karma-runner/karma https://github.com/karma-runner/karma [2]: http://sinonjs.org/ http://sinonjs.org/ [3]: https://github.com/jhnns/rewire https://github.com/jhnns/rewire
gondo 10y ago
i'm surprised this does not use Yarn
CoryG89 10y ago
We use usually use a mocha/chai/sinon combo for our testing. Can anyone that has used this make a comparison with that? Looks like jest tries to cover all three.
- aj0strow 10y ago
  I was using that too, and switched over to Jest + Chai Assert. It was too difficult for me to replicate features like file watching, run only tests with changes for faster feedback loop, transpiling typescript and es6 in the same project, asset mocking, starting and stopping timers, etc. I only really used sinon.spy() so traded it for jest.fn().
BJanecke 10y ago
This might be a bit frivolous. But Jest has gotten a whole lot better over the last few months. It used to be slow, cryptic and dogmatic. Now it's fast, transparent and open to debate. Great job Jest team! I would qualify that but I started this comment saying it was going to be frivolous. If enough people care however I'll expand on this.
franciscop 10y ago
I just migrated a project[1] to Jest. Now I totally think that Jest is AWESOME. Before I was mangling with Grunt and PhantomJS, but due to PhantomJS version being back ages I couldn't really test ES6 so I had to do a hybrid and running mocha in an actual browser, and the rest of the dev stack in grunt. Now I am able to do it all automatically. Not only that, but jest includes a browser by default which supports ES6 and an assertion library, so just with 'jest' I am doing the same that I did before with mocha, chai and PhantomJS (+ the pain of installing PhantomJS separately). I am not so much into React, but I just fell in love with Jest. Testing will be something totally different from now on, thank you Facebook. [1] http://github.com/franciscop/superdom.js http://github.com/franciscop/superdom.js PS, it was a bit more difficult to integrate Jest into Grunt and I get it without the colors, but I'm sure I'll find a solution soon-ish.

202 points by huan9huan 10y ago

I have used jest and i have used mocha. I use mocha because I got sick of having to "unmock" everything in jest tests. People have complained that jest is slow, that was never a problem I encountered. The unmock becomes very annoying after a while.

andyeskridge 10y ago
Jest has changed a lot lately. Back in September they changed the mocking to be opt-in. [1] The speed is also very much improved! [1] http://facebook.github.io/jest/blog/2016/09/01/jest-15.html#disabled-automocking http://facebook.github.io/jest/blog/2016/09/01/jest-15.html#...
wwalser 10y ago
I always used the option to turn it off by default. What you're left with (instead of having to unmock loads of stuff) is a parallel test runner with and a utility that is capable of mocking most anything upon command. They recently changed mocking to be opt-in.
Lazare 10y ago
When jest was first released, it was incredibly, glacially slow, buggy, poorly documented, and seemed to be largely unmaintained. Critical features were broken and stayed broken for months. I was an early adopter and I got burned hard, having to rewrite everything in Mocha. Since then, apparently, it has changed hugely, and is now fast, reliable, and pleasant to use. Or so I've heard; I have no particular reason to change back to jest, since mocha is fine. But if you're wondering why you've heard about it being slow, it's because for many, many months jest was absurdly, unbelievably slow; simple "hello world" tests would take seconds, and even a medium projects would take minutes. And there was no watch mode, nor any ability to re-run failing tests, or re-run tests on changed files. It was absurd. Edit: See, eg, https://github.com/facebook/jest/issues/116 https://github.com/facebook/jest/issues/116 opened 8 Aug 2014, and finally closed 17 Feb 2016. Quite a run. Also, there were tons of bugs with the mocking and, especially, the `dontMock()` methods; many things could cause attempts to turn mocking off to silently, invisibly fail (or even more fun, to cause an attempt to disable mocking on one item to cause it to be silently, invisibly disabled on all items). It's amazingly hard to track down a failing test when a bug triggered by code in another test can cause items that should be mocked to not be mocked, and visa versa.

haney 10y ago

I've been working on a React Native project and I really enjoy how easy jest is to use. It's hard to tell from this post though, is there something new/specific about it? Or are we all just agreeing that it's awesome?

wwalser 10y ago

I have a strange history with JS test libraries. Of the 4 that I've used, I've fixed bugs in 3 of them within a week of first picking it up. QUnit, Sinon and Jest. This isn't commentary on the quality of Jest. After turning off auto-mocking and instead only using the mocking when I really needed it, I ended up using it for a moderately successful side project and enjoyed the experience.

andrewstuart2 10y ago
Have you used jasmine + karma? That's been, and still is, my go-to for solid and fast testing.
- dancek 10y ago
  It's solid once you get everything set up, but that takes me a while. Of course I've only set it up for a couple of projects, using different build systems, and having tried other test libraries in between in order to minimize the chances of my remembering anything... I think there's room for one or two test frameworks that Just Work. Surely you'll lose some configurability, but mostly you don't need it.
- wwalser 10y ago
  I have used Jasmine+Karma. It's good stuff. It doesn't have the the "awesome stuff baked in" feel that Jest gives but it also doesn't give you a headache when something baked in doesn't work as expected :).
mambodog 10y ago
Automocking is off by default now, and a lot of work has been done to improve the developer experience in recent times.
- wwalser 10y ago
  Thanks for the work you & the team have put into Jest. While I haven't used it recently, I'm glad that it's out there as an option. The _ability_ to mock easily was always super great.

Nitramp 10y ago

This doesn't do browser testing (like Karma), it's just an alternative to mocha, right?

b34r 10y ago
Not out of the box, but the environment setup is easily configurable. I've been using a Protractor for my E2E tests since it also uses Jasmine... does the trick until there is more first-party support.
BJanecke 10y ago
It comes with jsDom baked into it for browser behaviour. Using a full headless browser to test with is not ideal, however I trust that you have a good reason to want that. If that is a requirement for you, you can tie jest up to karma :), but I beseech you to have a very good reason to test against a headless browser first :)
- Nitramp 10y ago
  Depends on what you want to test, I guess. If you want to test UI widget behaviour (not just business logic), then jsDom probably isn't the right tool and you need a browser. E.g. if you need CSS measurements or more tricky DOM behaviour. It's not entirely clear to me why you'd want a headless browser though. Once you're already running a browser, you might as well run a full one, and also get the debugging capabilities.

batmansmk 10y ago

The last versions are for us better than the other tool. The snapshot feature is pretty neat.

rileyt 10y ago

Jest used to have a lot of problems and was poorly maintained. Over the past few months, that has changed entirely. Improved speed, lots of bug fixes, snapshot tests and general ease of setup with React projects have all really helped. Jest is now the test framework I would suggest for anyone starting a new React project.

mullsork 10y ago
Agreed. We started using Jest in April 2015 or so and I hated it with a passion for well over a year. I can't remember exactly which version it was but it go improved by miles recently. Now my goto JS test library without a doubt.
endisukaj 10y ago
Has the documentation improved? Last time I checked it (about a year or so ago) it was terrible.
- shaneos 10y ago
  It's but a click away (and yes it has :-)) http://facebook.github.io/jest/docs/getting-started.html http://facebook.github.io/jest/docs/getting-started.html
- lacker 10y ago
  We've improved it some but there's more to go. If you have specific parts that you consider to be still-terrible let us know!
k__ 10y ago
Seems like it was a side project of some FB employees and it didn't get traction till a few months ago. Till then the project pretty much stalled.

wildpeaks 10y ago

Jest sounds good on paper, it's great it exists and it definitely has potential and even improved a lot recently (and I usually try every new version that come up), however I have two pain points with it that prevent me from switching to Jest for now: - it uses regexes instead of globs, so you can't just give it the list of tests like you would with Mocha or electron-mocha (e.g. something like "jest src/* * /*.tests.js") - it excludes paths that include "node_modules" and it's not just a default (which would be fine), it's hardcoded, so you can forget about local modules, or dependencies that use local modules Fortunately, there are already open issues for both, so that might improve in the future :) --- Edit: I had to add extra spaces in the glob example (so it's slightly incorrect) because HN formatting seems to prevent using "double star".

b34r 10y ago
Hey there, frequent Jest contributor here! Globs are under consideration (there's an issue from a collaborator on the subject.) FWIW, Jest is insanely good. I've been using it for almost 2 years now through some of the rougher patches in its development and man, it's an extremely well thought-out system with a team of highly motivated maintainers. Facebook uses it for almost all their JS projects, so it gets a LOT of attention and TLC. Many things that were poor defaults have been changed since v17, like getting rid of auto mocking. It's worth a look again.
cpojer 10y ago
I work on Jest at FB. * I agree regexes suck but that's all we had five years ago when it was started. Would love to move to a glob system incrementally but most of that will have to come from the community. I'm also still concerned about performance. We match things against tens of thousands of files a lot and regex seems strictly faster to me but I'm happy to be proven wrong or shown that it won't be relevant. * There is one minor issue with create-react-app's recommended use of node_modules to split up things. I would recommend lerna for multi-package development ( https://github.com/lerna/lerna https://github.com/lerna/lerna ) and we are hoping to put whatever fix in place here that will work well. There are workarounds but they aren't great.
- 10y ago

efrafa 10y ago

Are you forced to use expect().to... or you can plugin any assert library ? (I get the benefits of expect but I still prefer assert style)

ville 10y ago
You can use any assertion library and it will just work. At one point I was using Jest with Chai when migrating a codebase that happened to use Chai for assertions.

jcoffland 10y ago

There's no such thing as painless testing.

gotofritz 10y ago
If it ain't hurting, you ain't doing it right.
onion2k 10y ago
Maintaining disorganised code hurts a lot more than writing tests.
rpastuszak 10y ago
But it hurts so good. As opposed to the alternative, which is dealing with technical dept, spaghetti, legacy code, etc...
- amelius 10y ago
  Testing and technical debt/spaghetti code/legacy code are not mutually exclusive.
  - shados 10y ago
    you're right. But testing bad code is really really hard. So usually tested code is somewhat better overall, just because it's the easiest way to do it.
blauditore 10y ago
If you develop the tests along with the main code, it's usually less painful, except if there's a hunk of legacy code to integrate your new one with. Ok, this is probably the case for most developers...

petetnt 10y ago

Jest has taken great steps forward in the oast year and I see the momentum only going up. Kudos to the whole team!

aikah 10y ago

Still sticking to Jasmine. Simple and efficient and no need for nodejs to run tests.

orta 10y ago

I'm a big fan of Jest - if you're using Jest with Visual Studios Code, I'd recommend looking at my extension that gives you a mode IDE-like experience. https://github.com/orta/vscode-jest https://github.com/orta/vscode-jest

BJanecke 10y ago
That's pretty darned rad! Kinda like wallabyjs, but not hitting me over the head with a license :P
shados 10y ago
Tried it for the first time yesterday. It is pretty amazing and the productivity boost is crazy (it's one of those tools that changes the balance when you ask if testing is worth the time or not).
badthingfactory 10y ago
Thank you for this! I've been patiently waiting for someone more motivated and intelligent than myself to create a free inline test runner. You are my hero. Keep the project open source, free, and plop a donations button on the page and I'll be quick to open my wallet.

kybernetikos 10y ago

Snapshot testing overconstrains your tests, and encourages people who see tests breaking just to rerun the snapshot without thinking too much. The painlessness comes with a cost.

cpojer 10y ago
Hi! I work on JavaScript Tools at FB. There is a fantastic post by Ben McCormick about the up and downsides of this system: http://benmccormick.org/2016/09/19/testing-with-jest-snapshots-first-impressions/ http://benmccormick.org/2016/09/19/testing-with-jest-snapsho... Snapshots aren't the only feature of Jest; it is simply one assertion in our assertion library. There is a ton of other stuff in the framework that makes setting up a test environment and writing tests easier. My philosophy for building a test framework is to build a good feature set to help you out in any situation but the user should be in total control. This allows you to find the best way to test your code which I've found to be extremely subjective. The choice of test framework and test methodology seems almost religious at times and I've deliberately tried to stay away from these conversations.
- kybernetikos 10y ago
  Indeed, I'm not criticising Jest which most of our developers really like, merely criticising snapshot testing, which is one of the ways we are using jest. The Ben McCormick post does cover some of the issues with snapshot testing, particularly around lack of communication of developer intent. If you wrote a unit test that asserted that a tree of data looked exactly a particular way, when the only correctness/incorrectness criteria was whether or not a particular prop was present on one of the branches, then you've written a bad test. Using a snapshot means that your test fails when your code changes in ways that are still correct. It's a test that invites lots of false negatives, and the reason that is considered acceptable is because it makes it easy to update the test when it predictably gives you the false negative. Normally writing tests that depend on the exact implementation details of the code under test is considered a bad thing. I can't help but think that there are better solutions to this problem. Almost immediately after one of our teams started using snapshot testing, we had test breakages because an entirely different component that we used in an ancillary way had a semver minor change (added a new prop that was defaulted) and that broke tests (but not the app) in our component. Perhaps we're doing it wrong, but adding tests to packages that can trivially be incorrectly broken by your dependencies changing is fairly painful (and makes a mockery of semver).

krrkrrmjao 10y ago

do we really need MORE testing frameworks? the devs should join jasmine instead

spraak 10y ago

Two questions: 1. What good books (or repos) that use JS can you recommend for writing good tests? 2. What advantages does Jest have over Jasmine?

aj0strow 10y ago
RE: 2. Jest bundles Jasmine. It's primarily a test runner (like karma[1]) more than a framework. Jest includes mocking capabilities at the function level (like sinon[2]) and module level (like rewire[3]). It supports parallel execution, custom source code transpiling, file extension mocks (for webpack requires) and file watching. It favors large ES6 projects -- takes a second to start up. [1]: https://github.com/karma-runner/karma https://github.com/karma-runner/karma [2]: http://sinonjs.org/ http://sinonjs.org/ [3]: https://github.com/jhnns/rewire https://github.com/jhnns/rewire

gondo 10y ago

i'm surprised this does not use Yarn

CoryG89 10y ago

We use usually use a mocha/chai/sinon combo for our testing. Can anyone that has used this make a comparison with that? Looks like jest tries to cover all three.

aj0strow 10y ago
I was using that too, and switched over to Jest + Chai Assert. It was too difficult for me to replicate features like file watching, run only tests with changes for faster feedback loop, transpiling typescript and es6 in the same project, asset mocking, starting and stopping timers, etc. I only really used sinon.spy() so traded it for jest.fn().

BJanecke 10y ago

This might be a bit frivolous. But Jest has gotten a whole lot better over the last few months. It used to be slow, cryptic and dogmatic. Now it's fast, transparent and open to debate. Great job Jest team! I would qualify that but I started this comment saying it was going to be frivolous. If enough people care however I'll expand on this.

franciscop 10y ago

I just migrated a project[1] to Jest. Now I totally think that Jest is AWESOME. Before I was mangling with Grunt and PhantomJS, but due to PhantomJS version being back ages I couldn't really test ES6 so I had to do a hybrid and running mocha in an actual browser, and the rest of the dev stack in grunt. Now I am able to do it all automatically. Not only that, but jest includes a browser by default which supports ES6 and an assertion library, so just with 'jest' I am doing the same that I did before with mocha, chai and PhantomJS (+ the pain of installing PhantomJS separately). I am not so much into React, but I just fell in love with Jest. Testing will be something totally different from now on, thank you Facebook. [1] http://github.com/franciscop/superdom.js http://github.com/franciscop/superdom.js PS, it was a bit more difficult to integrate Jest into Grunt and I get it without the colors, but I'm sure I'll find a solution soon-ish.