You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When sinon.useFakeTimers is used in a nested fashion, or code crashes or early exist before a timer is restored, it becomes impossible to reset the timers to their default configuration.
Expected behavior
I expect there to be some way to get the original timers back.
Context:
When writing Mocha tests, often there are multiple nested describe blocks. If each block doesn't handle the timers correctly, particularly child blocks, then this can easily happen with no way to recover or reset. This gets particularly tricky if before* or after* blocks are used to fake timers and then an individual it block also messes with timers.
Additional context
Granted, all these cases above could be consider a bug or poor usage, but there really should be some way to get things back to normal. The problem was realized when trying to debug intermittent failures in tests (we randomize the order of our tests to catch stuff like this). It took quite a while to hunt this problem down. Then, the fix was rather painfully going through every place were a timer was used and making sure that, if a decedent test was using a timer, it was declared locally and cleaned up in a finally block. So, now our code has lots of try...finally in it where there was none before. Otherwise, an abnormal function termination would cause the fake timers to leak and break other tests.
The text was updated successfully, but these errors were encountered:
For the simplest case, it should not be too hard to make it work. https://github.com/sinonjs/fake-timers/blob/main/src/fake-timers-src.js#L1752 could just store references to the global timers and we could expose a reset() on the module. This should probably handle most issues, but the fake-timers module supports alternative contexts to be passed in, as would be the case for JSDOM tests, for instance, where you typically pass in some window to be used as the the global. Alterations to window would not be handled with the approach, as you would need to keep the context around somehow.
The source code is relatively easy to work with, so feel free to poke around to get some ideas on how this could be done.
I've created a PR to address this in the most uniform way I could think of, taking into account the problem of the JSDOM test that you mention. Please see sinonjs/fake-timers#426 and let me know what you think @fatso83 .
Describe the bug
When
sinon.useFakeTimers
is used in a nested fashion, or code crashes or early exist before a timer isrestore
d, it becomes impossible to reset the timers to their default configuration.To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect there to be some way to get the original timers back.
Context:
When writing Mocha tests, often there are multiple nested
describe
blocks. If each block doesn't handle the timers correctly, particularly child blocks, then this can easily happen with no way to recover or reset. This gets particularly tricky ifbefore*
orafter*
blocks are used to fake timers and then an individualit
block also messes with timers.Additional context
Granted, all these cases above could be consider a bug or poor usage, but there really should be some way to get things back to normal. The problem was realized when trying to debug intermittent failures in tests (we randomize the order of our tests to catch stuff like this). It took quite a while to hunt this problem down. Then, the fix was rather painfully going through every place were a timer was used and making sure that, if a decedent test was using a timer, it was declared locally and cleaned up in a
finally
block. So, now our code has lots oftry...finally
in it where there was none before. Otherwise, an abnormal function termination would cause the fake timers to leak and break other tests.The text was updated successfully, but these errors were encountered: