Better stack traces in asynchronous errors

[SimenB]

Do you want to request a feature or report a bug?
Feature

What is the current behavior?
There are three cases (that I know of) when a test is failing, and we don't point back to the user's own code.

test('some async test', () => {
  return expect(Promise.resolve('foo')).resolves.toBe('bar');
});

test('hasAssertions', () => {
  expect.hasAssertions();

  return Promise.resolve('foobar');
});

test('assertions', () => {
  expect.assertions(42);

  return Promise.resolve('foobar');
});

This renders the following errors:

If the current behavior is a bug, please provide the steps to reproduce and
either a repl.it demo through https://repl.it/languages/jest or a minimal
repository on GitHub that we can yarn install and yarn test.
See above.

What is the expected behavior?
For the stack trace to point back to the failing test. In the first case, I would expect it to point to the line of the expect, and in the the two other cases, to the lines specifying assertions.

I think the only way to achieve this is to somehow store an error whenever those functions are resolved, and use its stack on failure, instead of creating a new Error within Jest itself on failure. As long as we don't inspect the stack trace (unless we need it for an error), the overhead should be minimal.

If we get a good stack trace, we automatically get the codeframe as well.

Please provide your exact Jest configuration and mention your Jest, node,
yarn/npm version and operating system.
Jest@22.0.0, node@8.9.3

[SimenB]

For completeness, what I want as stack for all of those are:

  ● some async test

    expect(received).toBe(expected)

    Expected value to be (using Object.is):
      "bar"
    Received:
      "foo"

      1 | test('some async test', () => {
    > 2 |   return expect(Promise.resolve('foo')).resolves.toBe('bar');
      3 | });
      4 |
      5 |test('hasAssertions', () => {

      at Object.<anonymous>.test (test.js:2:10)

  ● hasAssertions

    expect.hasAssertions()

    Expected at least one assertion to be called but received none.

      4 |
      5 | test('hasAssertions', () => {
    > 6 |   expect.hasAssertions();
      7 |
      8 |   return Promise.resolve('foobar');
      9 |});

      at Object.<anonymous>.test (test.js:6:10)

  ● assertions

    expect.assertions(42)

    Expected 42 assertions to be called but received zero assertion calls.

      10 |
      11 | test('assertions', () => {
    > 12 |   expect.assertions(42);
      13 |
      14 |   return Promise.resolve('foobar');
      15 |});

      at Object.<anonymous>.test (test.js:12:10)

[SimenB]

Another case is timeouts.

We should at least point back to the test - maybe the it itself

[stopsopa]

Same here: #5902

[SimenB]

Opened up #6008. Combined with #5997 I think that covers all cases reported here except for throw 'something' or await Promise.reject('something') - that is thrown or rejected non-errors. I think we might want to point back to the test itself there (like with spec timeouts in my PR)? We have no way of accessing the real stack, as the rejection will always be async

[SimenB]

For those following along, a new alpha is out: jest@23.0.0-alpha.7. Please give it a whirl and report any remaining issues with traces 🙂