-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Testing: Evaluate Jest alternatives #2757
Comments
A bit of historical background: |
I was chuffed to discover AVA now includes snapshot testing, I'm leaning toward AVA for this reason for the ESLint and Stylelint repos where I currently use Jest snapshots. Gutenberg explored Jest snapshots previously in #1841 and #2018 though there is no usage of Jest snapshots currently |
It looks like Ava no longer uses |
Useful articles which should help with explorations of Jest alternative:
There is also this repository https://github.com/vitalets/js-testrunners-bench which contains JavaScript test-runners benchmarks. Results can be found here. We want to have Babel support so this is the most accurate benchmark which covers our use case. Ava doesn't seem to perform well there ... |
I figured out that @BE-Webdesign has already spent some time adding missing tests to the existing blocks, so it would be nice to hear his opinion here. |
I don't understand the legal stuff fully, so these comments will be disregarding that aspect. Jest probably makes the most sense for this project still, or any largeish project for that matter, purely on ease of setup. Mocha is great and with extra configuration, it can be made to run as fast as Jest. You can do snapshots in Mocha as well. Ava: have not used it, I am sure it would be fine as well. Tape is an option that I like a lot, but would most likely involve a much larger rewrite of the testing suite we already have, as it is more bare bones. It also might require refactoring some of our code. Nobody likes tape, and at this stage in the project, it would be a bad fit. QUnit, is already used by core, so that could definitely make sense to use that. The only difference is we should not do the tests in HTML like core does and instead use the CLI. QUnit uses TAP, like tape, so one of the benefits of tape is bound up in QUnit. There are probably other great options out there, but really it comes down to Mocha and Jest. Ever since Jest got rid of the auto mock everything setup, it has had a significant edge over Mocha. Factoring in the patent issues, which again I cannot comment on really, I would say going back to Mocha makes the most sense. Mocha is something most JS devs are comfortable with. We can do snapshotting and mimic many of Jest's features and performance characteristics, but it would require extra setup. It is hard to beat Jest on ease of use, performance, and ease of setup ( the three things that matter in a test runner ), but if the React decision impacts this as well, I think Mocha would be the clear choice, personally. |
Jest is now MIT Licensed: https://code.facebook.com/posts/300798627056246 |
you know what, If there's something I'm really happy about it being relicensed, it's Jest, even more than React |
Thanks @BE-Webdesign for the insightful reply 👍 I've not used Mocha much myself, nice to see snapshots appearing in more test frameworks, it's a fantastic feature... I've also not looked at QUnit apart from cores HTML usage, CLI mode would be best here...
I'm taking a calculated punt that this will also become MIT licensed as it's in the base React repo Jest, I do like Jest, a lot, it's watch mode is sweet as 👌 . Now that Jest is becoming MIT licensed though the general consensus here still appears to favor Jest just as it was previously in #1382, we should probably stick with Jest. |
So are we sticking with Jest? Please reply 'Yes' and close this issue out 😄. |
I don't see any reason to change now that Jest is (or soon to be) MIT licensed. That said, let's throw it out there in it the #core-js discussion in ~36 hours from now |
I think we are good with Jest with the latest announcement from FB. Personally, I'm more than happy with it. We still didn't explore the power of snapshots, so it can become even more useful for us. We can wait until the #core-js discussion, but it probably is going to be dominated by the topic of framework-agnostic blocks. Anyway, we can decide tomorrow. I'm all for closing this issue :) |
Closing in favor of Jest, re open if something comes up. Talking about this in JS meeting can resolve it as well. |
Previously: #1382
The ramifications of the Facebook patents grant decision extend beyond using React. In #1382, we ported from a Mocha test framework to using Jest. Jest is covered by the same patents grant:
https://github.com/facebook/jest/blob/master/PATENTS
Therefore, like React, we are in the position to be moving away from Jest. This could mean:
This ought to be the topic of a JavaScript Core Slack meeting, though the next scheduled meeting will be occupied primarily by discussion of frameworks and hooks.
EDIT:
react-test-renderer
is another lib that has patent grant.The text was updated successfully, but these errors were encountered: