-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Infinite loops seem to escape timeouts #1609
Comments
It seems like this is something that node does. For example, for the following node snippet, setTimeout(function() {console.log("test")}, 1000);
while (true) {} Unless there's some way to work around this, you might want to remove "auto-exit to prevent "hanging" with an active loop" from the homepage. |
It should be able to help with asynchronous loops: var i, test;
i = 0;
test = function() {
console.log(i++);
setTimeout(test, 1000);
};
test(); If a loop such as yours blocks the event loop, there isn't much opportunity for Mocha or any other function to jump in and stop it. |
You're probably right that it's a distinction we could make though :) Thanks for mentioning it. |
@akrs Just noticed you were referring to setTimeout(function() {
console.log(Date.now());
}, 10000);
it('test', function() {
console.log(Date.now());
});
Notice that mocha exit as soon as it's done running the test suite, and doesn't wait for the function that's set to be ran 10 seconds later. Hope that makes sense! :) |
I think, it is worth a sentence in the "Timeout" section on the website. A simple "an infinite loop will not cause a timeout, this is a limitation of node.js" would do just fine. |
I am writing now some babel plugins and I got bitten by this behaviour. Actually, there is a way to a break from 'unbreakable loops' for example using this library: https://github.com/tjanczuk/tripwire I am gonna take a closer look at it. |
I wrote a test where the fail condition would be an infinite loop. However, infinite loops seem to escape the normal mocha timeout. See trivial test case below:
The "does timeout" test fails as expected, but the "should timeout" test runs forever.
The text was updated successfully, but these errors were encountered: