question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Promises that never resolve skip subsequent tests

See original GitHub issue

I think this is a bug, but maybe I’m holding it wrong?

// tests/test.js
const { test } = require('uvu');

test('skips subsequent tests', async () => {
  await new Promise(() => {});
  throw new Error("isnt executed");
});

test("doesn't run", () => {
  throw new Error('doesnt run');
});

test.run();

This test file doesn’t fail and doesn’t run any tests. Tested in both node 16 and node 14.

Same behaviour using both the CLI and node directly.

$ npx uvu
tests/test.js

$ node tests/test.js
$

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Reactions:1
  • Comments:12 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
tom-shermancommented, Jun 24, 2022

After thinking about this a little I really think this is a separate issue to timeouts.

A test runner must ensure that test functions run to completion or throw an error. To me this is a core invariant a test runner must uphold. In other words tests should have two possible final states: “passed” and “failed”. Currently this behaviour in uvu introduces a third state of “not complete” but surfaces the result to the user as “passed”.

@lukeed Do you have any additional thoughts on this? I’d love for this issue to be reopened - I’m happy to implement @Katarn suggestion above.

Overall, this is something that your JS programs should not be doing

To summarise, I want to write tests to ensure that my JS programs aren’t falling into this trap.

1reaction
tom-shermancommented, Dec 9, 2021

@lukeed Sorry for not being clear about the original intention of this issue - the behaviour I’m describing is that tests are skipped in some scenarios, which could lead to false positive test passes.

Maybe I’m missing something but #33 appears to be a feature request to control the timeout of tests, I was raising a point about the first test in my example causing the second test not to ever execute.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Detecting a promise that will never resolve/ reject
I ran into an interesting JavaScript problem today: How to detect a promise that will never resolve/ reject?
Read more >
Testing: how to assert between two sequential promises/run ...
The problem, though, is that Ember will only execute both andThen tests once all the asynchronous execution has finished – this means that...
Read more >
Provide an API to flush the Promise resolution queue #2157
0.0 Promises never enter the resolve/reject functions and so tests fail. Our issue seems to be related this issue of not having an...
Read more >
Using promises - JavaScript - MDN Web Docs
A Promise is an object representing the eventual completion or failure of an asynchronous operation. Since most people are consumers of already- ...
Read more >
Testing Promise Side Effects with Async/Await - Rescale
all . When resolve is called on d1 (and d2 as well), Promise.all schedules a ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found