Always use workers when using the watch mode

[mjesun]

When using the watch mode, we use the TTY as an input mechanism (for keystrokes), so that different options can be selected. When only one test is selected, it will run by default in band, which causes the TTY to be unresponsive.

Blacklisting "in band" mode when using the watch mode fixes the issue, since tests are executed in workers, freeing the main process.

Fixes #6599.

[thymikee]

nice fix! can you also add watchAll?

[mjesun]

@thymikee done 🙂

I'll wait for the build to finish.

[SimenB]

Aaaah, great catch!

Missing changelog though :D

[SimenB]

Not sure it fixes 6599, though?

[mjesun]

@SimenB added too!

[thymikee]

@SimenB looks like it should fix it, now the main thread is not blocked

[mjesun]

@SimenB it fixes it. The issue is that they're executing jest with one single test, which forces it into runInBand mode. This works well for a non-interactive run, but it kills responsiveness if the test takes ~10 secs. From the original issue:

it completely freezes Jest until the test has run. Even if there's a typo we need to quickly fix. And we find it helpful to focus on a single test file.

[mjesun]

cc / @gaearon

changelog addressed

[cpojer]

Can you check out the comment here: #6599 (comment)

If we know the duration of the test, and the test runs faster than about three seconds can we run in band? The reason is that most people's tests are faster than that, so interrupting doesn't make sense. The single test run in band may be lots faster than than the startup time of node + reading a large haste map (at FB). Also consider how we may have an in-memory transform cache in the main process already. I think optimizing for that case is worth it because focusing on a single fast test is a common thing people do.

[mjesun]

I agree with the former, but if we go that way, I'd set up a one second limit. As stated by Nielsen, one second is about the limit for the user's flow of thought to stay uninterrupted.

[cpojer]

I'm fine with one second too. While this change makes things better for slow tests, I also wanna make sure we don't make it worse for all the fast tests out there.

[codecov-io]

Codecov Report

Merging #6647 into master will increase coverage by 0.02%.
The diff coverage is 50%.

@@            Coverage Diff             @@
##           master    #6647      +/-   ##
==========================================
+ Coverage   63.73%   63.76%   +0.02%     
==========================================
  Files         235      235              
  Lines        8935     8935              
  Branches        4        4              
==========================================
+ Hits         5695     5697       +2     
+ Misses       3239     3237       -2     
  Partials        1        1

Impacted Files	Coverage Δ
packages/jest-cli/src/test_scheduler.js	37.89% <50%> (ø)	⬆️
packages/jest-cli/src/reporters/utils.js	91.26% <0%> (+0.97%)	⬆️
packages/jest-cli/src/reporters/Status.js	95.38% <0%> (+1.53%)	⬆️

---

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 d16d420...ddbbaac. Read the comment docs.

[gaearon]

I'm trying this in Prepack, and it definitely fixes p to pause, but for some reason file system changes don't interrupt the test until it finishes. Is this expected?

[gaearon]

Here's a gif. I'm changing the code to something that would clearly break it. It doesn't interrupt the ongoing test.

Once the test prints success, I save the file again, and now it re-runs and shows failure (this part didn't fit in the gif but trust me it happens).

Testing methodology: I applied this patch alone to compiled test_scheduler.js on top of latest stable Jest.

[github-actions]

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.