No stack trace for exceptions in throws/notThrows

[CherryDT]

Description

When a test fails due to a t.notThrows throwing or a t.throws throwing the wrong type of exception, there is no stack trace in the output, only the toString representation of the error. This makes it hard to debug such issues.

Test Source

const test = require('ava')

function throwError () {
	throw new Error('uh-oh')
}

test('it shows no useful stack trace for t.notThrows encountering an exception', t => {
	t.notThrows(() => throwError())
})

test('it shows no useful stack trace for t.throws encountering unexpected exception types', t => {
	t.throws(() => throwError(), TypeError)
})

test('it does show useful stack trace for other exceptions', t => {
	throwError()
})

Output:

david@CHE-X1:~/z/Temp $ ava test.spec.js

  3 failed

  it shows no useful stack trace for t.notThrows encountering an exception
  /mnt/c/Users/david/Temp/test.spec.js:8

   7: test('it shows no useful stack trace for t.notThrows encountering an exception', t => {
   8:   t.notThrows(() => throwError())
   9: })

  Threw:

    [Error: uh-oh]




  it shows no useful stack trace for t.throws encountering unexpected exception types
  /mnt/c/Users/david/Temp/test.spec.js:12

   11: test('it shows no useful stack trace for t.throws encountering unexpected exception types', t => {
   12:   t.throws(() => throwError(), TypeError)
   13: })

  Threw unexpected exception:

    [Error: uh-oh]




  it does show useful stack trace for other exceptions
  /mnt/c/Users/david/Temp/test.spec.js:4

   3: function throwError () {
   4:   throw new Error('uh-oh')
   5: }

  Error thrown in test

  Error:

    [Error: uh-oh]

  throwError (test.spec.js:4:8)
  Test.t [as fn] (test.spec.js:16:2)

As shown here, only the last case prints a stack trace. I would like to see a similar output for the other two cases.

Environment

david@CHE-X1:~/z/Temp $ node -e "var os=require('os');console.log('Node.js ' + process.version + '\n' + os.platform() + ' ' + os.release())"
Node.js v7.6.0
linux 4.4.0-43-Microsoft
david@CHE-X1:~/z/Temp $ ava --version
0.19.1
david@CHE-X1:~/z/Temp $ npm --version
4.1.2

dflupu earned $80.00 by resolving this issue!

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on Issuehunt to raise funds.

[novemberborn]

Nice find!

We're only setting the stack for promises / observables, and even then we ignore the stack from the error itself. See

ava/lib/assert.js

Line 168 in 2b9f291

stack,

.

We should fall back to actual.stack if the stack variable is undefined. If it's not we should (somehow?) concatenate the two stacks. Ideally the coreAssert.throws() bit gets excluded but not to worry if we can't get rid of it.

If anybody wants to land a hand here that'd be great.

[parro-it]

As a simple workaround, I remove notThrows altogether:

test(`Convert accelerator`, t => {
	toKeyEvent(accelerator);
	t.is('silly', 'silly');
}));

I still not got the stack trace, but at least I can see the point in my code that throwed:

The "silly" part is to avoid Test finished without running any assertions check.

[skylize]

I think a useful fix for this would be a flag or function to instruct ava to not clean the stack. If I get an error and can't figure out why, it would be great to do something like t.useDirtyStack() at the top of my test or test.dirty( 'shows the whole stack', t => { throw } ) while I'm working so ava just dumps out whatever is there without trying so hard to be helpful.

[novemberborn]

The t.throws() implementation is being refactored in #1704. That PR does not address this issue, though hopefully the implementation is now easier to follow.

We're looking for the following solution:

We should fall back to actual.stack if the stack variable is undefined. If it's not we should (somehow?) concatenate the two stacks.

This refers to the AssertionError constructor in lib/assert.js which sets the stack property.

[norbertkeri]

Is this going to be fixed before 1.0? I'm evaluating whether to use ava for a new project, it's a bit uncomfortable to to manually edit failing tests to see the stack traces.

[novemberborn]

@norbertkeri it's not on the priority list, no. That said the aforementioned refactor has landed so if you'd like to help out with a PR, we can get it in 😉

[IssueHuntBot]

@issuehuntfest has funded $80.00 to this issue. See it on IssueHunt

[IssueHuntBot]

@dflupu has submitted a pull request. See it on IssueHunt