Timecop is freezing tests

[Turbo87]

We are using https://github.com/matteodepalo/ember-cli-timecop in a few component integration tests and until now this worked fine. We tried to convert those tests to use the new testing APIs, but now Timecop.freeze() seems to block the async render(...) call from continuing.

An issue similar to this has existed in the past where Backburner.js would not continue running when Date.now() is mocked and frozen, but was fixed by getting a reference to the Date object on startup and then using that reference instead of the temporary mocked global.

[Turbo87]

Since #239 was not merged yet it seems that we are not actually using setTimeout() at all yet, so it must something else using it 🤔

[rwjblue]

@Turbo87 - Well, Ember.run.next ultimately does use setTimeout internally (and we are using run.next now).

[rwjblue]

If you have the time, could you put together a repo I could use for testing / experimenting with this?

[Turbo87]

@rwjblue https://github.com/Turbo87/__timecop-issue

[Turbo87]

Interestingly jamesarosen/Timecop.js#24 (comment) notes that:

Timecop doesn't modify the global setTimeout and setInterval implementations.

I updated the issue description to reflect this.

I'm wondering what is causing these freezes then 🤔

[rwjblue]

The issue is exactly what you mentioned in the initial description. BackburnerJS/backburner.js@a6fe19e changed Date.now to no longer be eagerly captured. The Ember.run.next's that we are calling (in setupContext and setupRenderingContext) create a scenario where settled() would never resolve (since it internally used Date.now() to determine if it should run our scheduled callback).

However, I also tested this with the changes from #239 and it does pass. I suspect that any "real world" scenario would still fail though. Essentially any usage of run.next or run.later in an app would cause this specific regression...

[Turbo87]

How did this work before?

[Turbo87]

Oh, I understand... BackburnerJS/backburner.js#264 🤔

[rwjblue]

Well, even with the same Ember version if you used the older style ember-qunit setup (e.g. moduleForComponent) nothing actually sets up a run.next / run.later so we just don't fall into this trap. tl;dr its a dozy 😭

[rwjblue]

Hmm, @Turbo87 I vaguely think that we discussed this in slack and you mentioned it was no longer an issue (or at least you had worked around it)?

[Turbo87]

I'm not sure, but since #245 (comment) has a reproduction it should be relatively easy to verify whether this works now or not. In our real app I think we're using TimeCop.travel() now instead of .freeze() 🤔

[rwjblue]

kk, I'll try to pull it down and test...

[kiwi-josh]

We had/have a similar issue over at ember-mockdate-shim Ticketfly/ember-mockdate-shim#4