-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Conversation
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! |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
There was a problem hiding this 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': |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 Report
@@ 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
Continue to review full report at Codecov.
|
@thymikee tests done |
? runInBandWatch | ||
: runInBandNonWatch; | ||
// if runInBand set by config we do not try to compute the value | ||
let runInBand = this._globalConfig.runInBand; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 Sure i'll do the change and adjust testswatchAll
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
@thymikee ok! so for sure i tested and now For the case of the other guy regression with |
There was a problem hiding this 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); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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]), |
There was a problem hiding this comment.
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'; |
There was a problem hiding this comment.
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:
import * as testSchedulerHelper from './testSchedulerHelper'; | |
import {computeRunInBand} from './testSchedulerHelper'; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 🤔
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i feel really dumb now
it's working o O (same module)
https://stackblitz.com/edit/testing-import-vs-import-cqfvh3?file=src%2Fapp%2Ftest%2Ftest.spec.ts
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing changelog entry 🙂
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 |
Yeah, they reverted the previous change. Just find my pr to jest and revert it (posting from mobile, searching is a pita) |
* 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
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. |
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:
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 arunInBand
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.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
)