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

Improve failure output #891

Closed
sindresorhus opened this issue May 31, 2016 · 9 comments
Closed

Improve failure output #891

sindresorhus opened this issue May 31, 2016 · 9 comments
Labels
enhancement new functionality

Comments

@sindresorhus
Copy link
Member

With the following:

'use strict';
module.exports = function () {
    throw new Error('foo');
};
import test from 'ava';
import fn from './';

test('unicorn', t => {
    t.true(fn());
});

test('rainbow', t => {
    t.fail();
});

I get the following using the default reporter:

screen shot 2016-05-31 at 14 11 11

The current output is a bit messy and ambiguous. For example the stack trace indent is different for the two lines.

I've done a quick mockup of what I'd like it to look like:

screen shot 2016-05-31 at 14 18 29

Note that I reduced the indent of 2 failed from 3 to 2 spaces. And I changed failed with "foo" to Error: foo to make it clear it failed with an error and what type of error. Could be a ReferenceError for example which would be lost in the previous output.

Happy to improve upon it. I want our failure output to be as readable as possible.

Here's what I used to generate the mockup:

const chalk = require('chalk');

console.log(`
  ${chalk.red('2 failed')}

  unicorn
  ${chalk.red('Error: foo')}
   ${chalk.dim('module.exports (index.js:3:8)')}
   ${chalk.dim('Test.fn (test.js:5:9)')}

  rainbow
  ${chalk.red('Test failed via t.fail()')}
   ${chalk.dim('Test.fn (test.js:9:4)')}`);

Thoughts?

Is there a way we could improve the Test.fn name in the stack trace?

Should we place the filename:line:column first? Usually the function name isn't very useful, so it's usually the line:column you care about.

@jamestalmage
Copy link
Contributor

Should we place the filename:line:column first? Usually the function name isn't very useful, so it's usually the line:column you care about.

The main advantage of the current output is that it remains a valid stack trace. The only difference is that paths are relative to the basedir instead of absolute, and we filter some irrelevant ones. I think there are some advantages to keeping to the standard, namely for external tooling (WebStorm provides clickable stack traces).

@jamestalmage
Copy link
Contributor

Meh - scratch that, we also remove the leading at from each line. That is probably enough to break any stack trace regexp out there (I just tested, WebStorm doesn't linkify our stuff). Let's just do whatever looks best.

@sotojuan
Copy link
Contributor

sotojuan commented Jun 2, 2016

Working on this—looks good to me.

@sotojuan sotojuan self-assigned this Jun 2, 2016
@jamestalmage
Copy link
Contributor

Could we do this to make stack trace clickable in iTerm2?

@sindresorhus
Copy link
Member Author

@jamestalmage Yes, I was thinking the same. We should definitely do that.

@sotojuan
Copy link
Contributor

sotojuan commented Jun 3, 2016

BTW are we doing this for the type of errors shown or also the ones under knownFailureCount and rejectionCount/exceptionCount?

@sindresorhus
Copy link
Member Author

@sotojuan Yes, if they have output, they should be in this style.

@sindresorhus
Copy link
Member Author

sindresorhus commented Aug 14, 2016

I now noticed that the verbose reporter (ava --verbose) is also quite messy. We should fix that one too. Maybe we could even share some code between them. The output below 1 test failed should be exactly the same as the mini reporter.

screen shot 2016-08-14 at 19 47 54

@sindresorhus sindresorhus reopened this Aug 14, 2016
@sotojuan sotojuan removed their assignment Dec 20, 2016
@novemberborn
Copy link
Member

These areas have undergone lots of changes. The output is now a lot better and consistent between the mini and verbose reporters:

screen shot 2017-08-28 at 16 14 45

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

No branches or pull requests

5 participants