Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test_runner: mock setInterval uses wrong interval after first time #50381

Closed
mika-fischer opened this issue Oct 25, 2023 · 0 comments · Fixed by #50384
Closed

test_runner: mock setInterval uses wrong interval after first time #50381

mika-fischer opened this issue Oct 25, 2023 · 0 comments · Fixed by #50384
Labels
test_runner Issues and PRs related to the test runner subsystem.

Comments

@mika-fischer
Copy link
Contributor

Version

main

Platform

Linux s7 5.15.0-69-generic #76-Ubuntu SMP Fri Mar 17 17:19:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

test

What steps will reproduce the bug?

When a mocked setInterval timer is triggered, the timers runAt time is updated for the next time it should run here. However , the increment is actually always 1, since the boolean flag isInterval is stored in the timer here

Pull request incoming.

test("setInterval uses the wrong interval", async (t) => {
  t.mock.timers.enable({ apis: ["setInterval"] });
  const fn = t.mock.fn();

  setInterval(fn, 1000);

  assert.strictEqual(fn.mock.callCount(), 0);

  t.mock.timers.tick(1000);

  assert.strictEqual(fn.mock.callCount(), 1);

  for (let i = 0; i < 999; ++i) {
    t.mock.timers.tick(1);
  }

  assert.strictEqual(fn.mock.callCount(), 1);
});

fails with:

❯ ~/src/libs/node/node index.mjs
﹣ aborting setTimeout clears wrong timer (2.795504ms) # SKIP
﹣ aborting setTimeout after timer is already triggered clear wrong timer (0.20311ms) # SKIP
✖ setInterval uses the wrong interval (24.795796ms)
  AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
  
  1000 !== 1
  
      at TestContext.<anonymous> (file:///home/mfischer/src/tests/node-mock-timers/index.mjs:72:10)
      at Test.runInAsyncScope (node:async_hooks:206:9)
      at Test.run (node:internal/test_runner/test:631:25)
      at Test.processPendingSubtests (node:internal/test_runner/test:374:18)
      at Test.postRun (node:internal/test_runner/test:715:19)
      at Test.run (node:internal/test_runner/test:673:12)
      at async Test.processPendingSubtests (node:internal/test_runner/test:374:7) {
    generatedMessage: true,
    code: 'ERR_ASSERTION',
    actual: 1000,
    expected: 1,
    operator: 'strictEqual'
  }

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior? Why is that the expected behavior?

setInterval should use the correct interval

What do you see instead?

setInverval always uses interval 1 after first time

Additional information

No response

@mertcanaltin mertcanaltin added the test_runner Issues and PRs related to the test runner subsystem. label Oct 25, 2023
nodejs-github-bot pushed a commit that referenced this issue Nov 12, 2023
PR-URL: #50384
Fixes: #50365
Fixes: #50381
Fixes: #50382
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: Chemi Atlow <[email protected]>
Reviewed-By: James M Snell <[email protected]>
targos pushed a commit that referenced this issue Nov 23, 2023
PR-URL: #50384
Fixes: #50365
Fixes: #50381
Fixes: #50382
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: Chemi Atlow <[email protected]>
Reviewed-By: James M Snell <[email protected]>
UlisesGascon pushed a commit that referenced this issue Dec 11, 2023
PR-URL: #50384
Fixes: #50365
Fixes: #50381
Fixes: #50382
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: Chemi Atlow <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test_runner Issues and PRs related to the test runner subsystem.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants