Revert sync timeouts

[rubennorte]

Summary

#7074 made sync tests fail if they finished after the defined timeout. That's a breaking change whose benefits don't compensate the upgrade cost and there's a valid workaround to implement it in userland. See the comments in #6947.

Test plan

Unit and e2e tests.

[SimenB]

Since GitHub is being silly and not allowing me to comment inline:

---

Will this still report slow async tests as slow in the UI? (red in parens after the test name)

[rubennorte]

@SimenB I can do that in a different PR, as a fix. I didn't know that was part of the change and it should be properly isolated and documented in the CHANGELOG.

It's just a revert of the change, so it'll preseve the behaviour about slow tests.

[codecov-io]

Codecov Report

Merging #7259 into master will increase coverage by <.01%.
The diff coverage is 50%.

@@            Coverage Diff             @@
##           master    #7259      +/-   ##
==========================================
+ Coverage   66.55%   66.56%   +<.01%     
==========================================
  Files         237      237              
  Lines        9317     9307      -10     
  Branches        4        3       -1     
==========================================
- Hits         6201     6195       -6     
+ Misses       3115     3111       -4     
  Partials        1        1

Impacted Files	Coverage Δ
packages/jest-jasmine2/src/queue_runner.js	100% <ø> (ø)	⬆️
packages/jest-circus/src/event_handler.js	12% <0%> (ø)	⬆️
packages/jest-jasmine2/src/p_timeout.js	100% <100%> (+9.09%)	⬆️
packages/jest-circus/src/utils.js	21.13% <50%> (-0.13%)	⬇️

---

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 319329f...b08efbf. Read the comment docs.

[SimenB]

it should be properly isolated and documented in the CHANGELOG.

Good call, probably worth an e2e test

[SimenB]

As long as we still mark the test as slow/able to track the time spent correctly, I'm not against this.

[rubennorte]

@SimenB do you know in what case would timeouts fail if the user mocked the Date? I'm not able to repro.

[SimenB]

global.Date = {now: () => 0};

test('async', async () => {
  await new Promise(resolve => {
    setTimeout(resolve, 50);
  });
});

test('sync', () => {
  for (let i = 0; i < 10000; i++) {}
});

Master:

With binding now:

Removing the fake Date:

The sync one doesn't work as you removed the eager "test started now" code. It should display at all times

See: https://github.com/facebook/jest/blob/561b767b2db1e4306fefb310e3a7cc5e2e42d874/packages/jest-cli/src/reporters/verbose_reporter.js#L109

---

So not the timeouts actually, just the timing information we store on the test result

[SimenB]

That said, we should inject it similar to how we do Promise, since if you fake Date in a setupFile, it's mocked before Circus is loaded at all, meaning we bind the fake Date.now.

More likely than setupFiles - people have timers: 'fake' in their config after we land Lolex, which will mockout Date for now.

[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.