sinonjs / fake-timers Goto Github PK

Env Details:
lolex: 2.1.0
node: v6.9.2

Following script throws an error:

var lolex = require('lolex');
var clock = lolex.install({shouldAdvanceTime: true, advanceTimeDelta: 40});
setTimeout(() => console.log(1), 4000);

Error:

1
_stream_writable.js:396
  if (state.length === 0 && state.needDrain) {
           ^

TypeError: Cannot read property 'length' of undefined
    at onwriteDrain (_stream_writable.js:396:12)
    at afterWrite (_stream_writable.js:386:5)
    at runJobs (/Users/lohith.pinto/Development/stark/node_modules/lolex/src/lolex-src.js:183:18)
    at Object.tick (/Users/lohith.pinto/Development/stark/node_modules/lolex/src/lolex-src.js:550:9)
    at doIntervalTick (/Users/lohith.pinto/Development/stark/node_modules/lolex/src/lolex-src.js:411:11)
    at ontimeout (timers.js:365:14)
    at tryOnTimeout (timers.js:237:5)
    at Timer.listOnTimeout (timers.js:207:5)

What could be the issue ?

Hello,

After migrating from lolex 1.4.0 to 1.5.0, my tests fails with this exception:

     TypeError: Cannot set property 'hrtime' of undefined
      at uninstall (node_modules/lolex/src/lolex-src.js:360:39)
      at Object.clock.uninstall (node_modules/lolex/src/lolex-src.js:629:13)
      at bus.close.then.then (test/scheduling/testScheduler.js:64:57)

I'm using nodejs 6.2.0.

My tests use lolex this way:

Setup:

clock = lolex.install(context)

Tear down:

clock.uninstall()

lolex-src.js 1.5.0 seems to assume that the context object has a key named process.

Any idea regarding this ? Does this mean that compatibility was broken somehow ?

Test timeouts when I do have callbacks for native events in my code. removing fake timer from code makes it work again.

var test = require('tape');
var sinon = require('sinon');

test('1', (t) => {
  t.plan(1);

  var clock = sinon.useFakeTimers();

  var p = new webkitRTCPeerConnection({iceServers: []})
  p.createOffer(function(){ t.ok(true); }, function(){});
});

Chrome 50.0.2661 (Linux 0.0.0)

thank you

var clock = lolex.install();
var countInterval = 100;
var counts = [0,1,2,3];
function countFunc(count) {
    console.log(count);
}
function delayedExecutor(func, timeout, args) {
    setTimeout(function () {
        func.apply(null, args);
    }, timeout);
}
counts.forEach(function (count, index) {
    delayedExecutor(countFunc, countInterval * index, [count])
});
clock.tick(10);
clock.tick(110);
clock.tick(210);

In output you can see that 3 is also printed, which should be called after 300ms.
using lolex.createClock() will have the same effect.

Passing clock.setTimeout into a module should work when mocking something like

function RafPolyfill(opts) {
  var setTimeout = opts.setTimeout || window.setTimeout;

  return function rafPolyfill(listener) {
    setTimeout(listener, 0)
  }
}

I'd be used in tests like

test('polyfill works', function (assert) {
  var clock = lolex.createClock();
  var raf = RafPolyfill({ setTimeout: clock.setTimeout })

  var counter = 0;
  raf(function () {
    counter++
  })

  clock.tick(1)
  assert.equal(counter, 1)
  assert.end()
})

The other methods of clock should also work without a this context.

https://github.com/domenic/sinon-chai exists and is great. I haven't been able to find an equivalent for lolex.

• Is there one?
• If I were to write such a thing, would you want ownership of it?

Hey,

Domains/async hooks aren't really supported from what I can tell - if a timeout is registered from a given domain/async context lolex probably wants to run it in that context.

To reproduce:

~/Documents/OpenSource/lolex [performance-now] $ node
> var lolex = require('./src/lolex-src.js')
undefined
> var clock = lolex.install()
undefined
> process.hrtime() 
[ 0, 0 ]
> var timeout = setTimeout(() => console.log('lolexed'), 100);
undefined
> process.hrtime() // this is fine
[ 0, 0 ]
> clock.runAll() // this runs the timer correctly
lolexed
100
> process.hrtime() // not updated. 
[ 0, 0 ]

This also affects performance.now. Will take a look.

Currently when two handlers set to be called at the same time, lolex guarantees that they will be called in the order they were set.

For example in the following setup foo is always called first:

setTimeout(foo, 1000);
setTimeout(bar, 1000);

Although this is not guaranteed by the real implementations of setTimeout and friends:

• http://stackoverflow.com/questions/1776239/are-equal-timeouts-executed-in-order-in-javascript/5998338#5998338
• https://code.google.com/p/chromium/issues/detail?id=172587
• https://bugs.webkit.org/show_bug.cgi?id=111143

So while tests may pass, the code might fail in real life.

I suggest to add an option to clock.tick(ms[, shouldRunSimultaneousHandlersInReversOrder]) as an API for test writers who want to test against this problem. The option basically will affect these lines (maybe only last two ifs), I think.

More context: https://github.com/rpominov/kefir/issues/134 https://github.com/rpominov/kefir/pull/135
cc @agentme

importing lolex in certain module systems will throw Uncaught ReferenceError: global is not defined and adding a module entry point in package.json will fix this.

Hi guys, I would like to start using the new hrtime() support. This is in since January but it hasn't made it onto NPM yet. When do you intend to publish a new version on NPM?

Both browsers and Node.js handles timers with int32 and overflows on values above 2147483647. It would be good if lolex in some way fails in that case too.

Background:

I read about the maximum delay on setTimeout, and prepared a farTimeout to just recursively wrap the setTimeout with max timeout multiple times. But, using test first approach, I noticed that the setTimeout handled 90 days without problem, even though the docs said max ~25 days. Digging deeper, I realized that the sinon.useFakeTimers gave me a setTimeout that handled larger numbers than Node.js setTimeout.

Suggested solution:

I think something like this in addTimer function would make it behave more like the actual setTimeout:

const maxTimeout = 2147483647
if (timer.delay && timer.delay > maxTimeout) {
    timer.delay = (timer.delay + maxTimeout) % (maxTimeout * 2) - maxTimeout
}

…not making a pull request right now though since this was quite quickly thrown together; could make one if you think this is a good solution.

when use lolex.insatll and set shouldAdvanceTime to true,the clock pass slower than system time.so it would cause a litter deviation for a while.

In node, there are the global setTimeout and friends. In addition, there are require('timers').setTimeout and friends. If I need to mock both, I can do the following.

global.clock1 = lolex.install();
global.clock2 = lolex.install(require('timers'), 0, ['setTimeout']);

However, if a library uses both, I have to know when to call each of them (which could change between releases). It would be awesome if I could tell lolex.install to use a specified clock. In this case, I would make both mocks have the same clock.

If you want to use Lolex in a browser you can use the pre-built version available in the repo and the npm package. Using npm you only need to reference ./node_modules/lolex/lolex.js in your <script> tags.

The linked file doesn't actually exist.

Error would previously say "Aborting after running 1000timers, assuming an infinite loop!" (notice the lack of space between 1000 and timers). There should be a space there.

const clock = require('lolex').createClock(0)
clock.setTimeout(() => console.log('tick'), -10)
clock.runAll()
console.log(clock.now)

This gives:

tick
-10

I think https://github.com/sinonjs/lolex/blob/4e1fdcf24f0adfca3b121dd51ff7505bb705a61b/src/lolex-src.js#L208 should use Math.max(0, parseInt(timer.delay)).

Currently these negatively delayed timers aren't triggered by clock.tick() either, though clock.next() works.

I think we should be moving towards plain node style packages and let browserify generate the boilerplate. What do you think?

I'm having an issue with a test that works fine on versions 1.5.1 and below that does not seem to work on 1.5.2 (using Jest + Enzyme). Following the README, this should work just fine, but seems to be having issues. Here's a sample of the code for reference:

import React from 'react';
import {shallow, mount} from 'enzyme';
import lolex from 'lolex';

import ResponsesSearch from 'js/responses/components/search/index';

  it('calls #applySearchTerm on submit', () => {
    const clock = lolex.install();
    const searchTermFn = jest.fn();
    const wrapper = mount(
      <ResponsesSearch applySearchTerm={searchTermFn} />
    );
    const input = wrapper.find('input');

    input.node.value = 'blah';
    input.simulate('change'); // we have an onChange callback on this input after 500ms

    clock.tick(500);

    expect(searchTermFn).toHaveBeenCalledWith('blah');

    clock.uninstall();
  });

I can provide more code if needed, but I'm wondering if I'm doing something wrong here with the implementation of lolex with:

const clock = lolex.install();
clock.tick(500);
clock.uninstall();

Any help would be appreciated!

Calling date.setHours(x) will set the hours in local time, regardless of useFakeTimers calls. This results in different behavior depending on the time zone in which the code is run.

Here's some code, with outputs in different time zones.

Not sure if this is a technical limitation or bad behavior.

In this example, we are faking the timers, creating a new Date(), and then printing it. It is created in the given time zone. Then, we call date.setHours(8). Rather than setting the hour to 8am in the fake time zone, it sets it to 8am in the system local time zone every time. Below I try with my computer set to Boston time, and then SF time.

Code

const sinon = require('sinon')

function tryTime(time, name) {
  console.log(' ', name)
  const clock = sinon.useFakeTimers(time)
  const date = new Date()
  console.log(date.toUTCString())
  date.setHours(8)
  console.log(date.toUTCString())
  clock.restore()
  console.log()
}

tryTime(Date.UTC(2015, 1, 25, 12, 0, 0, 0), '7am in Boston')
tryTime(Date.UTC(2015, 1, 25, 7, 0, 0, 0), '7am in London')
tryTime(Date.UTC(2015, 1, 24, 4, 0, 0, 0), '7am in Beijing')

Computer set to Boston (EST) time

  7am in Boston
Wed, 25 Feb 2015 12:00:00 GMT
Wed, 25 Feb 2015 13:00:00 GMT

  7am in London
Wed, 25 Feb 2015 07:00:00 GMT
Wed, 25 Feb 2015 13:00:00 GMT

  7am in Beijing
Tue, 24 Feb 2015 04:00:00 GMT
Mon, 23 Feb 2015 13:00:00 GMT

Computer set to San Francisco (PST) time

  7am in Boston
Wed, 25 Feb 2015 12:00:00 GMT
Wed, 25 Feb 2015 16:00:00 GMT

  7am in London
Wed, 25 Feb 2015 07:00:00 GMT
Tue, 24 Feb 2015 16:00:00 GMT

  7am in Beijing
Tue, 24 Feb 2015 04:00:00 GMT
Mon, 23 Feb 2015 16:00:00 GMT

I'm not sure if my loopLimit isn't being used, if I'm getting the wrong message, or if I instantiate incorrectly, but I do something like this:

let lolex = require( 'lolex' );
let clock = lolex.install( 0, ['setTimeout', 'clearTimeout'], 1000000000000 );

let firstCalled = false;
let secondFunc = function () { firstCalled = true; }

// Will trigger a bunch of other `setTimeout` calls
runFirstFunc( foo, secondFunc );

setTimeout(function() {
	if ( !firstCalled ) { doSomething( bar ); }
}, 30 );

clock.runAll();

I use more timeouts than that, but that's the gist.

No matter how big I make the loopLimit number, I often, but not always, get similar messages at random points in the tests (usually one somewhere random near the end and then a bunch at the very end - the specific pattern probably has more to do with the way in which I'm running the tests) :
"(node:21049) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Aborting after running 1000 timers, assuming an infinite loop!"

Note: the "node" has also been 21260, 21264, 21201, etc., and when I've had multiple messages, the rejection id changes, but the "node" number will stay the same for all of them

The number of timers is always 1000, no matter the number I set for the limit. I get the messages even if all my tests succeed.

Environment:
node v6.9.1
MacBookPro v10.11.6

This isn't super important, but even if there have been too many loops, shouldn't this fail at the same point each time? I've gotten different results even when I've run the same set of tests.

Also, is it possible to pass the loopLimit to .runAll(), i.e. clock.runAll( 5000 )? That would make more sense to me and would also be more flexible.

How much work would it be to support faking the timezone? Is this even possible?

Over at node-schedule there are repeated issues due to daylight savings time changes (see node-schedule/node-schedule#267). I was just about to write some tests when I realised that the tests will only work (or rather... only fail!) if the person running the tests also has their timezone set to the same localtime as me. If the timezone is different, the bug will occur at different times. If they are using UTC, the bug will not occur at all.

So I would like to be able use lolex and tell it to pretend we are in a particular timezone, regardless of what the system timezone actually is. My suspicion is that this may not even be possible.

Any thoughts?

Thanks.

Hey,

What's with that warning? Upgrading Sinon's minor version number broke my tests, which seem to be caused by Lolex. Downgrading to Sinon v1.15 (with an older ver of Lolex) removed the warning and tests continued to work. No setTimeout mocking necessary.

Thanks!

I'm having an issue where Lolex seems to be incompatible with Bottleneck, a popular rate-limiting package. Bottleneck schedules callbacks using setTimeout, and if I mock those calls using Lolex, only the first callback gets called for some reason.

I initially thought it might be a Bottleneck issue, but then I proceeded to replace Lolex with my own API-compatible implementation, and the problem went away (for my example code).

Maybe I'm misunderstanding Lolex. At any rate, thanks.

Hey,

Thanks for the quick release, we have 4 failing tests when updating to 2.0.0 because of old code that relied on lolex.install(Date.now()) or something similar. (I fixed the code on our side)

I think that lolex should either throw a TypeError when a date is passed directly or it should accept that as the timestamp.

I don't mind working on either suggestion - what do you think?

Issue #103 introduced a new API. The tests were updated, but not the README. We need to document the new API, as can be seen from #108

As mentioned in the docs: https://github.com/sinonjs/lolex#var-clock--lolexcreateclocknow-looplimit

The now argument may be a number (in milliseconds) or a Date object.

However, this does not work for a Date object.

It seems as though this line (https://github.com/sinonjs/lolex/blob/f464603ef78b585aabb1ad461b26a3267989536c/src/lolex-src.js#L620) needs to be modified to:

if (typeof target === 'number' || target instanceof Date) {
  // ...
}

This isn't a lolex bug per se, but a gotcha that I wanted to report here just in case anyone else runs into it!

If you use jQuery 2/3, $.now() will not respect lolex's fake timer. jQuery 1.x used to respect it. This is because jQuery 2/3 captures a reference to Date.now at load time, before lolex gets a chance to stub it out. You see results like this:

> Date.now()
< 36000000

> (new Date).getTime()
< 36000000

> $.now()
< 1468845725858

The jQuery docs claim "The $.now() method is a shorthand for the number returned by the expression (new Date).getTime().", but that's not quite right - it's defined as now: Date.now, which captures a reference to the original unstubbed method.

I know you might to say "use bower"...but no. React devs use npm for everything these days, including for the browser, and we're used to npm packages working in both node and the browser (i.e. via webpack).

Usually when I need access to the global object, I do

var global = (new Function("return this"))()

Works in node and the browser.

Alternative you could call your bootstrap function with

(typeof global !== 'undefined' ? global : this)

(see http://stackoverflow.com/questions/3277182/how-to-get-the-global-object-in-javascript)

Whether you want to use that or some other solution, please make sure that src/lolex-src.js works even if accessing global would cause a ReferenceError.

Since this module is supposed to power Sinon in the future, we should remove the dependency, or replace it with a dependency on a pure sinon-stub module (once that is available).

My function give resutl in respect to current date, I use sinon.useFakeTimesrs for that. I was trying few ways untill start to write it inside test itsel, and call restore() in the end of test.

  describe('myFunc', function () {
    it('test case', function () {
      const clock = sinon.useFakeTimers(new Date('2017-09-23T00:00:00.00Z'));
      ...
      clock.restore();
    });
  });

But this approach has problems: if any test, which useFakeTimers, fails, then that other test restore function not called, making many tests fail as well, because of wrong date.

Other approach was to put useFakeTimers in beforeEach and afterEach hooks, and then redefine this.clock in each test. That fails, because for some magic reason this.clock in afterEach appear to be undefined!

  describe('myFunc', function () {
    beforeEach(function () {
      this.clock = sinon.useFakeTimers();
    });
    it('test case', function () {
      this.clock = sinon.useFakeTimers(new Date('2017-09-23T00:00:00.00Z'));
      ...
    });
    afterEach(function () {
     this.clock.restore(); // cannot read property restore of undefined
    });
  });

How to do this right, so all tests with fakeTimers were idependent?

Hi guys,
NPM lists lolex 1.5.0 but package.json on Github is 1.4.0. Maybe forgot to commit?

Soon, when nodejs/node#14680 lands the performance API (and tests) should be added to Node.js by lolex when running.

I'll work on it when it lands.

I've recently had to speed up timeouts to speed up some tests. I wrote something along the lines of this:

oldInterval = window.setInterval
clock = lolex.install(window)
oldInterval(function() {
  clock.tick(1000)
}, 100)

Having something like this in lolex could be a nice addition: clock.engageWarpSpeed(multiple)

clock.engageWarpSpeed(10) // 10 times faster
clock.engageWarpSpeed(2) // 2 times faster

Is this something that you consider merging if I open a pull request?

Schedules the callback, to be fired once 0 milliseconds have ticked by.

The other descriptions don't have a comma.

npm test invokes npm run lint which fails, AFAICT due to checked style violations that have been present in the code for a long time.

If I remove that step the tests pass but having npm test fail on a clean checkout and install of the development repository leaves an unjustified negative impression of lolex's quality.

> [email protected] test /opt/Node/lolex
> npm run lint && npm run test-node && npm run test-headless


> [email protected] lint /opt/Node/lolex
> jslint src/**/*.js


src/lolex-src.js
 #1 Wrap this regexp in parens to avoid confusion.
    if (l > 3 || !/^(\d\d:){0,2}\d\d?$/.test(str)) { // Line 56, Pos 22
 #2 Unexpected 'for'.
    for (prop in source) { // Line 103, Pos 8
 #3 Unexpected 'arguments'.
    switch (arguments.length) { // Line 144, Pos 20
 #4 Unexpected '++'.
    timer.id = uniqueTimerId++; // Line 176, Pos 32
 #5 Unexpected 'for'.
    for (id in timers) { // Line 236, Pos 8
 #6 Unexpected 'for'.
    for (id in timers) { // Line 254, Pos 8
 #7 Unexpected 'eval'.
    eval(timer.func); // Line 278, Pos 16
 #8 Unexpected 'for'.
    for (i = 0, l = clock.methods.length; i < l; i++) { // Line 340, Pos 8
 #9 Expected ';' and instead saw ','.
    for (i = 0, l = clock.methods.length; i < l; i++) { // Line 340, Pos 18

npm ERR! Linux 3.13.0-83-generic
npm ERR! argv "/usr/local/Node-v4.4.0/bin/node" "/usr/local/bin/npm" "run" "lint"

performance.now is not being faked when installing.

a workaround would be

window.performance.now = Date.now;

as timing api is becoming more and more common this should be part of the lib

Hi,
first of fall, thanks for your work. It is a nice library very useful when using dates…

Just, I think the createDate function breaks the actual native Date creation, essentially when it is used with one parameter.
For new Date(value) value could be:
• an Integer value representing the number of milliseconds since 1 January 1970 00:00:00 UTC (Unix Epoch);
• an String value representing a date. The string should be in a format recognized by the Date.parse() method

In the lolex createDate, the value represents only the year of the new Date.
Then, the result is not as really expected.

I'd like to use this library for acceptance tests (ie. running the web app + JS frontend in a browser / phantomjs) that involve time-dependent data, so the clock needs to be set back to a certain date. My app also uses lodash' debounce function, however, which relies on the passage of time. Because I don't really have a good place to put a tick statement the clock shouldn't be 'frozen' at a particular moment but it should advance as normal from the system date specified.

This would like the travel method of Timecop.js (which is deprecated in favor of sinon / lolex.)

A good test doesn't mock more than it needs to. Thus I would expect that when I call clock.uninstall() there would be no uncalled timers left.

Yet sometimes I suck at writing tests and would have a false positive / negative, or even worse, a silent error dangling in a setImmediate that never got called.

It would be tremendously helpful if we could log a warning (or throw) when there are uncalled timer functions. Either by default, or as an option.

I believe that an installation should also run process.nextTick calls if possible to simulate correct timer flow.

Currently, lolex ignores process.nextTick calls which go out of order when testing Node calls :)

Fixing would look like:

• detect if nextTick is present.
• If it is, override it like setTimeout
• Whenever timers are run - always before the next timer - call the nextTick callbacks in order registered.

Hey,

At the moment promises won't get called in tests using lolex. I think it would be cool if promises ran under lolex too.

Basically:

• Override Promise.prototype.then (which always defers running callbacks to the next tick).
• If the clock progresses (in any way) - run pending promises as well.
• On uninstall - run all promise callbacks remaining in nextTick and resume standard operation.

Since promises resolve synchronously (but only are acted on asynchronously) that should work.

We also need to patch Promise.resolve since that is called implicitly whenever a function is awaited in an async function.

Do you think this is in scope for lolex? If it is - can start working on it. If not - where would this belong?

novemberborn/ksuid@b4564c5 hangs when tests are run in Node.js 8.2.0, but is fine in 8.1.4.

The fix is to not fake nextTick: novemberborn/ksuid@7239faa

Tests are run using AVA, which does not directly uses process.nextTick(). I'm not sure why it the hangs occur with Node.js 8.2.0 either. It does seem that faking nextTick by default may result in unexpected behavior.

I am trying to set the system time and then run all asynchronous code in a test like this:

var clock = lolex.install();
clock.setSystemTime(moment.utc('2016-04-01').valueOf());
clock.runAll();

But it seems that the method is not defined:

TypeError: clock.runAll is not a function

Could you please point me in the right direction. Thank you!

lolex: 1.4.0
nodeJs: 5.2

Underscore 1.6.0 to 1.8.3 stores Date.now, mandating Date.now to be stubbed before loading Underscore for fake clocks to work. Affected functions include _.debounce, _.throttle, and probably more.

This is an issue with Underscore, not Lolex. Lolex can work around this by replacing Date.now upon installation, but this will end up faking Dates created before installation and end up breaking other, more valid, uses.

Underscore no longer uses Date.now in master, and lodash seems to work as well. This issue is just here for informational purposes.

Facebook's Jest testing library has a couple of methods that make it easy to run all the timers:

Run All Timers

• https://facebook.github.io/jest/docs/timer-mocks.html#run-all-timers

This runs all pending timers until there are none remaining. If new timers are added while it is executing they will be run as well.

Run Pending Timers

• https://facebook.github.io/jest/docs/timer-mocks.html#run-pending-timers

This runs all the pending timers until there are none remaining. Any new timers that are added while it is executing are not run.

Would there be any interest in adding similar functionality to lolex? I'm happy to look into doing the work if so.

To recreate:

• Go to https://jsfiddle.net/yexyLdj7/ - This uses the latest version of lolex-src.js from master.
• Run the fiddle.

What happens:

• The browser throws the error:
  lolex-src.js:623 Uncaught ReferenceError: global is not defined

What should happen:

• No error!

It looks like it is caused by this line: https://github.com/sinonjs/lolex/blob/master/src/lolex-src.js#L392

I'm not sure how to write a test that shows this issue!

Currently the list of timers is stored as a flat, unsorted object space.

We may improve performance by maintaining an array of timers-to-be-executed, explicitly sorted according to their eventual execution order.

New timers could be inserted using a binary search insertion, turning the current O(1) operation to an O(logn) operation, but turning the execution-time cost from the current O(n)-ish to O(1).

Try http://sinonjs.org/releases/sinon-timers-1.17.3.js

the line where the error occurs. defunctzombie/node-process@774a338#diff-de1a5a7de991855714cdf433e9f8be96R11

I've a test setup with karma and webpack. I'm getting this error on Chrome 50.0.2661.102 (64-bit). I've also tried with 1.12.2, 1.17.3 and pre 2.0 versions of sinon but still no luck. there is no error when I just use sinon on bare html page without any transpilers, webpack or libraries. this issue seems to related with this defunctzombie/node-process#49

I can inspect this error and help you to reproduce but I like get a few quick ideas about how to resolve this first, if you guys run across with the same problem before.

thank you.