There are a few fundamental concepts regarding the timers in Backburner.js:
platform.nextshould not be able to be affected by fake timers. If it is then the run loop would never advance for auto-runs and would be impossible to flush.
platform.setTimeoutplatform.clearTimeoutshould be able to be affected by fake timers. This allows consumer APIs like Ember.run.later / Ember.run.next / Ember.run.debounce / Ember.run.throttle to be controlled with sinon.useFakeTimers or lolex.
platform.nowshould be able to be affected by fake timers. This allows Ember.run.later (and other future scheculing API's like debounce) to schedule work in the future relative to the current fake clock.
This PR resolves the original bug (caching the setTimeout that is used by platform.setTimeout in module scope), and adds explicit tests using the most common "fake timers" system (lolex which is what sinon uses) to help ensure this is clearer in the future.
There are a few fundamental concepts regarding the timers in Backburner.js:
platform.nextshould not be able to be affected by fake timers. If it is then the run loop would never advance for auto-runs and would be impossible to flush.platform.setTimeoutplatform.clearTimeoutshould be able to be affected by fake timers. This allows consumer APIs likeEmber.run.later/Ember.run.next/Ember.run.debounce/Ember.run.throttleto be controlled withsinon.useFakeTimersorlolex.platform.nowshould be able to be affected by fake timers. This allowsEmber.run.later(and other future scheculing API's likedebounce) to schedule work in the future relative to the current fake clock.This PR resolves the original bug (caching the
setTimeoutthat is used byplatform.setTimeoutin module scope), and adds explicit tests using the most common "fake timers" system (lolex which is what sinon uses) to help ensure this is clearer in the future.Fixes #351