Skip to content
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

fix: TestScheduler now take in count the runInBand config #7518

Merged
merged 6 commits into from
Dec 24, 2018
Merged

fix: TestScheduler now take in count the runInBand config #7518

merged 6 commits into from
Dec 24, 2018

Conversation

nasreddineskandrani
Copy link
Contributor

@nasreddineskandrani nasreddineskandrani commented Dec 15, 2018

Summary

In our team we add test file per file. So we run mostly by command line, webstorm extension, vscode extension against one file at a time.

In command line by using:

npm run jest -- --runTestsByPath path\to\a\spec\file.spec.ts --runInBand --watch

The problem is in the jest 23 we realized a regression comprared to 22.
I documented it here:
#7110 (comment)

the solution
In test scheduler runInBand args value was not considered. An algorithm was computing a runInBand variable.
As a user of jest, i want the test scheduler to use the arg runInBand value if i supply it.
So we don't want to rely on any algorithm to alter the value when we know already that it is ALWAYS better with a specific value coming from args (in this case true).

Test plan

Before my fix:
i added a console log for the runInBand variable inside TestScheduler file.
image

sometimes as you can see it was using false

After my fix:
It will be always using the command line arg if present which give us optimal time run (always) with the command line mentionned on top (since it remains always true)

@facebook-github-bot
Copy link
Contributor

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

@facebook-github-bot
Copy link
Contributor

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

Copy link
Collaborator

@thymikee thymikee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Um, how did we miss that? Please add a regression test so we don't break it again :)

@@ -682,6 +682,7 @@ export default function normalize(options: InitialOptions, argv: Argv) {
case 'watch':
case 'watchAll':
case 'watchman':
case 'i':
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should state runInBand, i is an alias

Copy link
Contributor Author

@nasreddineskandrani nasreddineskandrani Dec 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks
as you can see when i did my code cleanup => i didn't retest it
(working with a baby in one hand and the other one in the keyboard ^^)
I was also missing another file change for my fix (added)

I'll add tests 🙈 => wanted to have a first feedback.

@codecov-io
Copy link

codecov-io commented Dec 16, 2018

Codecov Report

Merging #7518 into master will decrease coverage by 0.24%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #7518      +/-   ##
==========================================
- Coverage   67.73%   67.48%   -0.25%     
==========================================
  Files         247      248       +1     
  Lines        9513     9517       +4     
  Branches        5        5              
==========================================
- Hits         6444     6423      -21     
- Misses       3067     3092      +25     
  Partials        2        2
Impacted Files Coverage Δ
packages/jest-cli/src/testSchedulerHelper.js 100% <100%> (ø)
packages/jest-cli/src/TestScheduler.js 72.5% <100%> (-0.89%) ⬇️
packages/babel-jest/src/index.js 40.74% <0%> (-34.26%) ⬇️
packages/jest-runner/src/index.js 75% <0%> (-1.2%) ⬇️
packages/jest-runtime/src/index.js 76.99% <0%> (-0.42%) ⬇️
packages/jest-resolve-dependencies/src/index.js 97.43% <0%> (-0.3%) ⬇️
...ages/jest-worker/src/workers/ChildProcessWorker.js 88.09% <0%> (-0.28%) ⬇️
packages/jest-runtime/src/script_transformer.js 88.46% <0%> (-0.08%) ⬇️
packages/expect/src/matchers.js 99.38% <0%> (-0.01%) ⬇️
packages/jest-util/src/installCommonGlobals.js 100% <0%> (ø) ⬆️
... and 23 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9208ac6...10123ac. Read the comment docs.

@nasreddineskandrani
Copy link
Contributor Author

nasreddineskandrani commented Dec 16, 2018

@thymikee tests done

? runInBandWatch
: runInBandNonWatch;
// if runInBand set by config we do not try to compute the value
let runInBand = this._globalConfig.runInBand;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, now I remember. We do this on purpose, because it's easy to leave runInBand in the config and make it look like Jest is slow all the time. See: #3215

So, it's only supported through CLI args on purpose:
https://github.com/facebook/jest/blob/700e0dadb85f5dc8ff5dac6c7e98956690049734/packages/jest-config/src/getMaxWorkers.js#L14-L17

The correct fix would be to add this._globalConfig.maxWorkers <= 1 condition to runInBandWatch, can you make that work?

Copy link
Contributor Author

@nasreddineskandrani nasreddineskandrani Dec 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok i see! this will fix also the regression with watchAll Sure i'll do the change and adjust tests

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@nasreddineskandrani
Copy link
Contributor Author

nasreddineskandrani commented Dec 16, 2018

@thymikee ok! so for sure i tested and now runInBand supplied assure that a run on one file with watch is fast as in v22 which is solving the problem i flagged. I added a test to catch the remove of the condition again in futur :P So i think we are ready to merge :) your call. (thanks for the help)

For the case of the other guy regression with watchAll on windows it'll not solve the problem since he doesn't use explicitly runInBand.
i have some ideas on what can cause it... to don't elaborate here
=> i'll take the other problem in a second PR during the week if no one solves it.

Copy link
Collaborator

@thymikee thymikee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM :) @SimenB mind taking a look?

// If we are confident from previous runs that the tests will finish
// quickly we also run in band to reduce the overhead of spawning workers.
const areFastTests = timings.every(timing => timing < SLOW_TEST_TIME);

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

Copy link
Contributor Author

@nasreddineskandrani nasreddineskandrani Dec 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done ( I'll commit all review in one - be patient)


test('slow tests', () => {
expect(
computeRunInBand(getTestsMock(), false, undefined, [2000, 500]),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like it would make sense to refactor all these tests to test.each, what do you think? :)

@@ -29,8 +29,7 @@ import SummaryReporter from './reporters/summary_reporter';
import TestRunner from 'jest-runner';
import TestWatcher from './TestWatcher';
import VerboseReporter from './reporters/verbose_reporter';

const SLOW_TEST_TIME = 1000;
import * as testSchedulerHelper from './testSchedulerHelper';
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to import by name, because why not:

Suggested change
import * as testSchedulerHelper from './testSchedulerHelper';
import {computeRunInBand} from './testSchedulerHelper';

Copy link
Contributor Author

@nasreddineskandrani nasreddineskandrani Dec 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i need this import to be able to use spyOn in the tests.
do you have an example on how to spyOn if i change the import?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the same module, so it shouldn't matter 🤔

Copy link
Contributor Author

@nasreddineskandrani nasreddineskandrani Dec 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://stackblitz.com/edit/testing-import-vs-import?file=src%2Fapp%2Ftest%2Ftest.spec.ts
example online with jasmine since i don't have jest on stackblitz but it doesn't matter for our case :)
It shows you the problem with spyOn with your import proposition. You can fork and fix it if you have a way to solve it

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how's that related. Check out my latest commit to this PR

Copy link
Contributor Author

@nasreddineskandrani nasreddineskandrani Dec 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

@nasreddineskandrani nasreddineskandrani Dec 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thymikee for some reason i assumed it was failing by old experience... my bad it's all fine
Thanks for the fix (i corrected a bad assumption in my head that was following me :P)

Copy link
Member

@SimenB SimenB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing changelog entry 🙂

packages/jest-cli/src/testSchedulerHelper.js Outdated Show resolved Hide resolved
packages/jest-cli/src/testSchedulerHelper.js Outdated Show resolved Hide resolved
packages/jest-cli/src/testSchedulerHelper.js Show resolved Hide resolved
@nasreddineskandrani
Copy link
Contributor Author

nasreddineskandrani commented Dec 21, 2018

@thymikee @SimenB review pass done. One comment (for the import) left with an answer.

@thymikee
Copy link
Collaborator

Looks like Node 8 changed the error messages again :|. Can you adjust that? https://github.com/facebook/jest/blob/master/e2e/__tests__/failures.test.js

@SimenB
Copy link
Member

SimenB commented Dec 21, 2018

Yeah, they reverted the previous change. Just find my pr to jest and revert it (posting from mobile, searching is a pita)

@nasreddineskandrani
Copy link
Contributor Author

@thymikee @SimenB done

@nasreddineskandrani
Copy link
Contributor Author

nasreddineskandrani commented Dec 21, 2018

thanks for the review :) i learnt things @SimenB @thymikee


looking forward for this merge to move on to the watchAll problem flagged for windows. since no one started it i guess I'll do it. I am on vacations for 2w tomorow so i have time to deal with it :)

@SimenB SimenB merged commit 3c7b110 into jestjs:master Dec 24, 2018
captain-yossarian pushed a commit to captain-yossarian/jest that referenced this pull request Jul 18, 2019
* refactor: review - check for runInBand via worker count in test scheduler watch mode case

* test: updates tests for computeRunInBand

* refactor: code review

* doc: update CHANGELOG

* fix; failure on CI due to node8 changes

* use named exports instead of asterisk
@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants