jest: Speedup slow e2e tests
Here’s a totally unscientific list of our slowest tests (times doesn’t really matter, it all depends on machine, but if you’re curious this is on MBP 2015, 8 cores, 2nd run with warm cache):
e2e/__tests__/jasmineAsync.test.js (36.086s)
e2e/__tests__/snapshot.test.js (56.125s)
e2e/__tests__/toMatchInlineSnapshot.test.js (58.722s)
e2e/__tests__/errorOnDeprecated.test.js (83.333s)
e2e/__tests__/failures.test.js (44.999s)
e2e/__tests__/toMatchSnapshot.test.js (88.268s)
e2e/__tests__/coverageReport.test.js (96.158s)
e2e/__tests__/onlyChanged.test.js (98.087s)
e2e/__tests__/coverageThreshold.test.js (45.632s)
e2e/__tests__/transform.test.js (60.83s)
e2e/__tests__/mockNames.test.js (36.544s)
e2e/__tests__/globals.test.js (43.55s)
e2e/__tests__/each.test.js (33.104s)
e2e/__tests__/findRelatedFiles.test.js (36.346s)
e2e/__tests__/customReporters.test.js (45.161s)
e2e/__tests__/globalTeardown.test.js (33.038s)
e2e/__tests__/testPathPatternReporterMessage.test.js (30.985s)
e2e/__tests__/filter.test.js (20.721s)
e2e/__tests__/env.test.js (24.019s)
e2e/__tests__/globalSetup.test.js (27.017s)
e2e/__tests__/stackTrace.test.js (27.964s)
e2e/__tests__/detectOpenHandles.js (24.307s)
e2e/__tests__/config.test.js (24.529s)
e2e/__tests__/toThrowErrorMatchingInlineSnapshot.test.js (26.213s)
e2e/__tests__/timeoutsLegacy.test.js (23.311s)
e2e/__tests__/watchModePatterns.test.js (21.548s)
e2e/__tests__/toThrowErrorMatchingSnapshot.test.js (21.85s)
e2e/__tests__/jestChangedFiles.test.js (36.407s)
e2e/__tests__/console.test.js (22.244s)
packages/jest-runtime/src/__tests__/runtime_cli.test.js (23.2s)
e2e/__tests__/setupFilesAfterEnvConfig.test.js (19.104s)
e2e/__tests__/testFailureExitCode.test.js (19.079s)
e2e/__tests__/multiProjectRunner.test.js (104.954s)
The way to speed them up is to simply split them into smaller chunks – maybe 2, maybe 3 or 4, it all depends – to better use parallelization.
Example:
onlyChanged.test.js -> onlyChangedGit.test.js + onlyChangedHg.test.js
If anyone feels adventurous enough to split any of the tests, let us know in the comments and send a PR 😃
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 4
- Comments: 34 (12 by maintainers)
@orofbrown I would say if in doubt smaller PRs are better, very large tends to become hard to review. The test duration being vastly higher when other things are being run makes sense due to system load, I would say if compared to
jest old-big-test,jest split-test-1 split-test-2 split-test-3takes less time overall that’s a good enough indicator that the split is worth itHey, can i work on it, if it is still open. It seems an interesting first issue for getting familiar with oss
Hey! this looks interesting to me. Can I take this up?
You should run Jest from the root. Just
yarn jest e2e/__tests__/multiProjectRunner.test.js(or./jest e2e/__tests__/multiProjectRunner.test.js) for instanceGotcha, thanks! (pinged you since you left 👀, sorry if it’s irrelevant)
I haven’t (and won’t). Feel free to pick some!
Here’s the sorted list, probably it’s better to start from the “slowest” items:
@nicollbryla @SimenB hey guys, have you already taken some of these files?
Hi, we would love to accept your contribution! As far as splitting tests goes, looking at the existing
describe/it/testblocks to see which belong together and using your intuition to determine where a split could be made should work well - there’s often multiple valid points to split anyway 😉Hi, I would like to give it a shot. Do you have more suggestions? Or should I trust my own intuition?