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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expanded Timeout Error Messages #2454

Closed
wants to merge 6 commits into from
Closed

Expanded Timeout Error Messages #2454

wants to merge 6 commits into from

Conversation

RobertWHurst
Copy link

@RobertWHurst RobertWHurst commented Aug 26, 2016

The timeout error now provides feedback about how the test timed out, and how Mocha expected the test to yield. The purpose of this change is to aid developers when debugging timeouts, especially the case where both done() is requested and a promise is returned. It also removes "Resolution method is overspecified" error as it had a similar effect, but could introduce problems when used with CoffeeScript or async functions from ES7.

The error messages are perhaps rough copy. I think the maintainers a best suited to re-word the errors if they see it as necessary. Add you suggestions below and I'll update them. That goes for the code too of course.

The following tests:

describe('Test timeouts', () => {

    it('Async test timeout with done()', (done) => {});

    it('Async test timeout with done() and promise', (done) => {
        return new Promise(() => {});
    });

    it('Async test timeout with promise', () => {
        return new Promise(() => {});
    });
});

Results in the following test output:



  !!!

  0 passing (615ms)
  3 failing

  1) Test timeouts Async test timeout with done():
     Error: timeout of 200ms exceeded. Expected done() callback to be executed but it never was.
      at null.<anonymous> (lib/runnable.js:244:19)

  2) Test timeouts Async test timeout with done() and promise:
     Error: timeout of 200ms exceeded. Expected done() callback to be executed but it never was. A Promise was returned, but ignored because done() was requested. Remove done() from your test arguments to use the promise instead.
      at null.<anonymous> (lib/runnable.js:244:19)

  3) Test timeouts Async test timeout with promise:
     Error: timeout of 200ms exceeded. Expected the returned promise to resolve but it never did.
      at null.<anonymous> (lib/runnable.js:244:19)



cc: @dasilvacontin, @boneskull

馃嵒

@RobertWHurst
Copy link
Author

RobertWHurst commented Sep 2, 2016

@dasilvacontin Any thoughts? I'm curious what you think of this approach.

@dasilvacontin
Copy link
Contributor

I personally prefer when code stuff is surrounded with backticks. So Promise -> Promise, and done() -> done (I don't think the parenthesis are necessary).

Also, given that this is a common error, we should consider adding an url/link to a Wiki page with some examples, and behaviour explanations, specially once we solve doubts at #1320.

@dasilvacontin
Copy link
Contributor

Also, we will not remove:

  if (result && utils.isPromise(result)) {      
    return done(new Error('Resolution method is overspecified. Specify a callback *or* return a Promise; not both.'));      
  }

until we make a decision about the behaviour.

Thanks for kickstarting the improved error messages. :)

@RobertWHurst
Copy link
Author

@dasilvacontin Sounds good. I'll split the PR (timeout messages vs yielding) and make the changes to the error messages. 馃憤

@@ -365,11 +379,11 @@ Runnable.prototype.run = function(fn) {
}
return done(new Error('done() invoked with non-Error: ' + err));
}
if (result && utils.isPromise(result)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revert

@@ -227,7 +228,20 @@ Runnable.prototype.resetTimeout = function() {
if (!self._enableTimeouts) {
return;
}
self.callback(new Error('timeout of ' + ms + 'ms exceeded. Ensure the done() callback is being called in this test.'));

var errorMsg = 'timeout of ' + ms + 'ms exceeded.';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once L368-L370 is reverted, will the logic here need to change?

@boneskull
Copy link
Member

This appears to address #2521, in theory

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants