Conversation
4703747 to
14eb31a
Compare
87fc694 to
b0a93e8
Compare
|
The snapshot-related cli tests are still failing. I think I have a theory as follows:
|
|
@boneskull Is it possible to have something as follows to be picked up by 'use strict';
exports.mochaHooks = {
beforeAll() {
console.log('beforeAll');
},
beforeEach() {
console.log('beforeEach');
},
afterAll() {
console.log('afterAll');
},
afterEach() {
console.log('afterEach');
}
}; |
dcb0093 to
377a949
Compare
bajtos
left a comment
There was a problem hiding this comment.
I am not happy with using root-level hooks for snapshot setup and want to investigate different approaches to see if I can find a more elegant solution. I am planning to work on this tomorrow (Friday), please give me few more days before continuing with the solution proposed here.
|
Let's not mix the upgrade to Mocha v8.x with the transition to parallel tests please. I'd like to see a standalone PR to upgrade to Mocha 8.x and make the necessary updates in our config files. I think commits like cbba724 and f9af11e can be landed independently too. Mocha 8.x dropped support for |
|
agree that parallel mode shouldn’t be the default for users. |
5d9b6b8 to
0268f67
Compare
BREAKING CHANGE: We have upgraded to `mocha@8.0.1` and removed support for `--opts` and `test/mocha.opts`. It may break your application if it depends on earlier version of `@loopback/build` for `npm test`. See a list of breaking changes of mocha 8.x at: https://github.com/mochajs/mocha/releases/tag/v8.0.0
…sting - try with require to register root hooks - add .mocharc.js for packages/cli to register root hooks - add the option to use env var MOCHA_JOBS to override parallel testing parameters
0268f67 to
20da28e
Compare
|
@raymondfeng can you please extract 7334f20 in to a standalone pull request to get it landed sooner, and make it easier for others (me in particular) to experiment with different approaches to parallel testing? |
| // memory leak detected. 11 SIGTERM listeners added to [process]. | ||
| // Use emitter.setMaxListeners() to increase limit | ||
| // It only happens when multiple app instances are started but not stopped | ||
| process.setMaxListeners(16); |
There was a problem hiding this comment.
How is the change in setMaxListeners(16) relevant to snapshot matching? I think this belongs to a different commit.
| // Resolve `./test/snapshot-matcher.js` to get the absolute path | ||
| const mochaHooksFile = require.resolve('./test/snapshot-matcher.js'); | ||
| debug('Root hooks for --require %s', mochaHooksFile); | ||
| const config = {...mochaConfig, timeout: 5000}; |
There was a problem hiding this comment.
I find this approach brittle because it requires us to deal with root hooks both inside the package test setup and in monorepo test setup.
There was a problem hiding this comment.
In #5724, I have proposed a fix that does not leak the knowledge about snapshot hooks outside of CLI tests.
| mochaOpts.splice(lang, 2); | ||
| } | ||
|
|
||
| // Set `--parallel` for `@loopback/*` packages |
There was a problem hiding this comment.
I am not sure if this is a good idea, because it affects code outside our monorepo too. Two examples:
-
Example projects created via
lb4 example <name>. Besides the extra complexity related to parallel testing, I am concerned about the impact on performance. Based on my measurement,examples/todotests are ~15x slower when executed in parallel:examples/todo$ npm t (...) 29 passing (481ms) examples/todo$ npm t -- --parallel (...) 29 passing (7s) -
External repositories like https://github.com/strongloop/loopback4-example-shopping. I am not sure how much work is required to support parallel testing in the shopping example and I would rather not block upgrading to the latest
@loopback/buildversion until we can figure out parallel testing.
I am proposing to enable parallel testing by changing npm run mocha script to add --parallel flag to mocha CLI options.
There was a problem hiding this comment.
See e.g. b44c7ee
-"mocha": "node packages/build/bin/run-mocha --lang en_US.UTF-8 --timeout 5000 \"packages/*/dist/__tests__/**/*.js\" \"extensions/*/dist/__tests__/**/*.js\" \"examples/*/dist/__tests__/**/*.js\" \"packages/cli/test/**/*.js\" \"packages/build/test/*/*.js\"",
+"mocha": "node packages/build/bin/run-mocha --lang en_US.UTF-8 --timeout 15000 --parallel \"packages/*/dist/__tests__/**/*.js\" \"extensions/*/dist/__tests__/**/*.js\" \"examples/*/dist/__tests__/**/*.js\" \"packages/cli/test/**/*.js\" \"packages/build/test/*/*.js\"",Having said that, I think it's time to move flags from run-mocha CLI args into the monorepo-level .mocharc.js file. That way they are always applied, for example when running a subset of tests manually via node packages/build/bin/run-mocha path/to/some/files.
|
Opened #5813 to rework the snapshot matcher to use Mocha global hooks, without actually enabling the parallel mode yet. |
| const config = {...mochaConfig, timeout: 5000}; | ||
|
|
||
| // Allow env var `MOCHA_JOBS` to override parallel testing parameters | ||
| const jobs = +process.env.MOCHA_JOBS; |
There was a problem hiding this comment.
I feel we don't need to support process.env.MOCHA_JOBS as it's already possible to change the number of jobs (worker processes) by using -j command line argument and disable parallel execution by setting the number of jobs to 1.
$ npm run mocha -- -j 1
|
I am proposing to close this pull request in favor of #5831. |
Enable parallel mocha testing - see #3159 (comment)
I'm starting to break down this PR into a few smaller ones:
Checklist
👉 Read and sign the CLA (Contributor License Agreement) 👈
npm testpasses on your machinepackages/cliwere updatedexamples/*were updated👉 Check out how to submit a PR 👈