Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Tests: Setup Jest as an alternative test runner #1382
This is a proof of concept for Jest integration with Gutenberg.
Wondering why Jest? See: https://gziolo.pl/2017/06/17/picking-jest-over-mocha/.
Sidenotes: It doesn't need Webpack processing. It still uses Chai and Sinon to make it possible to run with both Mocha and Jest and perform comparisons on one branch. I had to disable one test suite, because I didn't find a quick way to make it pass. It can be done later if we ever decide we replace Mocha with Jest.
Regular test run
With slow tests:
Only one test file (element/test/index.js):
By default it executes test for modified files only. You can change it using UI for subsequent runs.
Jest is configured to omit Webpack processing step. It makes it faster even when executed with all caches disabled. Jest shines on subsequent runs when it's able to take advantage of its caching mechanism.
Jest without cache
Copying my comments for our slack discussion here:
Before introducing a new testing framework to Core, we need to consider the different options and Jest is a great test runner (maybe the best right now)
One of the issues we currently have with our mocha setup is that we build the tests using webpack (pegs-loader, sass-loader, wp global variables are all handled by webpack) before running them, this has some costs. We can’t run a single test without building the entire suite which is not very performant.
This PR solves this issue
I personally think the niceties that come with Jest surpass the downsides: Performance, coverage, snapshots.
It would be great to have others' opinion.
Found this an interesting read, results were not what I expected:
p.s. I do like watch, cache, snapshots features of Jest FWIW
I saw that the other day, too. This benchmark is very interesting but I noticed that Jest is executed with default configuration, which means it needs to setup a fresh jsdom instance for every test suite. You can pick node test env instead which should drastically speed up things and will align with what Mocha and Jasmine offer out of the box. Jest's default setup is optimized for code that is run in the browser.
I asked post's author to add Jest setup that uses node as test env. I'm looking forward to see how it would impact results.
@ntwb I got confirmation form benchmark's author that Jest is 30% faster with test env set to node. See https://medium.com/@vitaliypotapov/thanks-for-suggestion-jest-is-really-30-faster-with-env-node-option-the-chart-4309ba8aba81. It still slower in this particular case though.