Make now configurable so time can freeze outside of backburner

[pittst3r]

The main purpose of this PR is to initiate a discussion around the problem of freezing time while using Backburner. With PR #166 (and #12941 in Ember) we lost the ability to monkey-patch Date.now without stopping Backburner from running. The use case for freezing time is in testing. Being able to peg time to an arbitrary point while testing time-related things is invaluable in preventing non-determinism.

My proposal is to somehow make the concept of "now" configurable and this PR is my first pass at it, mostly a proof-of-concept. It would also be nice to have an explicit public API (as opposed to doing something like Ember.run.backburner._platform = … which makes me feel like I'm being bad–even just removing the underscore would be nice).

Looking forward to hearing y'alls thoughts. Thanks!

[stefanpenner]

There are many things that depend on a monotonically increasing system clock. Rather then patching all of them, clock stubbing libraries should likely just handle this.

If #166 broke the ability to stub time, because it now looks up Date.now(), it is likely because the time stubbing library was loaded after BB. Would it be simpler to go back to not looking up Date.now dynamically?

---

Also , it would be very useful to be describe the failure scenarios #166 introduced

---

Alternatively, an approach I have found quite good, is for my system to just use a shared clock abstraction. Which I control, and replace if needed. This leaves things like BB alone, but makes time aspects of my application work via the shared clock abstraction.

[pittst3r]

If #166 broke the ability to stub time, because it now looks up Date.now(), it is likely because the time stubbing library was loaded after BB.

That's precisely what's going on. After #166, Date.now gets evaluated after one has the chance to monkey-patch Date. Going back to not looking up Date.now dynamically sounds like a great solution.

I'll go back and update the PR accordingly and see if I can add some tests to paint a fuller picture.

[pittst3r]

Okay, this is updated now. What do you think? I do like this better and like that it simply protects backburner from outside interference.

I wasn't able to come up with any failure scenarios other than the one described in the test I wrote. Basically #setTimeout will not tick if Date.now is not captured before the monkey patch.

Alternatively, an approach I have found quite good, is for my system to just use a shared clock abstraction. Which I control, and replace if needed. This leaves things like BB alone, but makes time aspects of my application work via the shared clock abstraction.

Thanks, that's an excellent suggestion. I'll look into doing this.

[toranb]

@stefanpenner any chance you could give the code @robbiepitts has a look this week? Although I'm in favor of using a clock abstraction as you suggest, this is technically a regression and I'd love to see if we can fix it (so users who had a passing test suite on ember 2.3 don't break as they continue to upgrade ember over time)

[stefanpenner]

I believe I am good with this change. Would love another r? to sanity check:

@rwjblue r?

[stefanpenner]

paired with @rwjblue who gives 👍