Mocha: [Proposal] Make timeout message configurable

[euoia]

When a test times out the following message is displayed:

Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.

This is pretty helpful, but in some cases it could be more helpful to display a custom message.

I propose adding an option to Runnable such that you can do something like this:

this.timeoutMessage('Check the server is running.');

Such that the output now becomes:

Error: timeout of 2000ms exceeded. Check the server is running.

I'm happy to create a PR if this is likely to be accepted.

[boneskull]

I'm not convinced this is necessary. It seems to add complexity with little benefit for the vast majority of users.

Keep this is mind for future plugin API

[bookercodes]

I think it'd be nice to customize the timeout error, too.

Sometimes Express application code does not end the request response cycle which causes the serer to hang, at which point Mocha throws a timeout error - it would be nice if I could specify a more useful error.

[bananu7]

@boneskull So thanks to your decision I'm now implementing a custom timeout routine so that my tests can fail with a meaningful message when a timeout is expected just before mocha decides to stop me.

:thumbsdown:

[boneskull]

@bananu7 This is unfortunate, but the reality of the situation is we don't have enough resources to add any given feature to Mocha's core w/o a significant outpouring of support for it. I'm working on a prototype of a new version which has a proper programmatic interface (think plugins) which would make this sort of thing easy to implement.

Is the following helpful?

// untested
describe('foo', function() {
  let timeout;
  this.timeout(0);

  beforeEach(() => {
    timeout = setTimeout(() => {
      throw new Error('custom timeout');
    }, 2000);
  });

  afterEach(() => clearTimeout(timeout));

  it('should not timeout', done => setTimeout(done, 200));

  it('should timeout', done => {});
});

[bananu7]

Well, it's essentially what I've done. It just felt weird to reject a ready PR that added this but I can kinda understand the reasoning behind not adding new things that will need further support down the line.

Thanks for reminding me about timeout 0 having special meaning, though.

[boneskull]

@bananu7 That's what it's all about. If we added every single feature anyone ever wanted, Mocha would be twice the mess it is already. :unamused:

[brookjordan]

I know it's old, but would seriously like this.
Designers are reading my test code so the ability to change the timeout error would be fantastic.

Something like:

describe('useful timeout errors', async function() {
  this.timeout(30000);

  this.timeoutErrorMessage = `Couldn't find element "${selector}".`;
  let parent = await waitForElement(selector);

  this.timeoutErrorMessage = `Couldn't find children "${childSelector}" of "${selector}".`;
  let children = await parent.findElements(childSelector);

  // ... tests;
});

[mrgenixus]

I know it's old, but would seriously like this.
Designers are reading my test code so the ability to change the timeout error would be fantastic.

Something like:

describe('useful timeout errors', async function() {
  this.timeout(30000);

  this.timeoutErrorMessage = `Couldn't find element "${selector}".`;
  let parent = await waitForElement(selector);

  this.timeoutErrorMessage = `Couldn't find children "${childSelector}" of "${selector}".`;
  let children = await parent.findElements(childSelector);

  // ... tests;
});

This is literally why I want this feature. If it were contributed by me or my team, would mocha's team consider merging it?

[boneskull]

@mrgenixus Do you have a recent or real-world code sample of what you're doing instead? This sounds like it lands squarely in the realm of features for functional testing, so I'm curious what tools/libs you're using with it.

[brookjordan]

Thanks for chiming in, @boneskull:

It's testing a website of which I can't access the codebase via tests, due to it being built in a sandboxed CMS.

The code above is, actually, very close to real-world code which is still being used and updated. I'm using it along with selenium-webdriver.

waitForElement is one of a plethora of functions I've built to make it easier for said designers to update the test suite. But right now when they read the error messages given they find it difficult to understand the problems due to poor understanding of the stack-trace.