Option to limit the number of lines of a stack trace shown

[holgerd77]

Showing the full stack trace of an error is a new feature of tape introduced with versions > 4.6.3, see #330 (comment).

While often being helpful, there are test setups where this information is useless (example below) and very much bloats the test output, making debugging a lot harder.

An option to limit the number of lines of a stack trace shown would help a lot in these context, see also discussion here: #330 (comment)

# file: TransactionCollisionToEmptyButNonce test: TransactionCollisionToEmptyButNonce
not ok 421 the state roots should match
  ---
    operator: equal
    expected: |-
      'fa7506ff5573eda0d388803c869e9da859e3bdf1c2d50e73ed88a205ba5a88e7'
    actual: |-
      'ca530e56f5b770cc7768ca7006985c4cccd5e205d12f271b36aac531933c6428'
    at: replenish (/Documents/DEV/EthereumJS/ethereumjs-vm-main/node_modules/async/dist/async.js:946:17)
    stack: |-
      Error: the state roots should match
          at Test.assert [as _assert] (/Documents/DEV/EthereumJS/ethereumjs-vm-main/node_modules/tape/lib/test.js:212:54)
          at Test.bound [as _assert] (/Documents/DEV/EthereumJS/ethereumjs-vm-main/node_modules/tape/lib/test.js:64:32)
          at Test.equal.Test.equals.Test.isEqual.Test.is.Test.strictEqual.Test.strictEquals (/Documents/DEV/EthereumJS/ethereumjs-vm-main/node_modules/tape/lib/test.js:347:10)
          at Test.bound [as equal] (/Documents/DEV/EthereumJS/ethereumjs-vm-main/node_modules/tape/lib/test.js:64:32)
          at /Documents/DEV/EthereumJS/ethereumjs-vm-main/tests/GeneralStateTestsRunner.js:98:9
          at /Documents/DEV/EthereumJS/ethereumjs-vm-main/node_modules/async/dist/async.js:3853:24
          at replenish (/Documents/DEV/EthereumJS/ethereumjs-vm-main/node_modules/async/dist/async.js:946:17)
          at iterateeCallback (/Documents/DEV/EthereumJS/ethereumjs-vm-main/node_modules/async/dist/async.js:931:17)
          at /Documents/DEV/EthereumJS/ethereumjs-vm-main/node_modules/async/dist/async.js:906:16
          at /Documents/DEV/EthereumJS/ethereumjs-vm-main/node_modules/async/dist/async.js:3858:13
  ...
not ok 422 the state roots should match

[ljharb]

I'd think this would need to be an option in test(), as well as t.test(), as well as to tape on the CLI.

I'd expect it to support a positive or negative nonzero integer; -3 would only include the last 3 lines, 3 would only include the first three.

Other alternatives include a regex that can be used to filter the trace line; any suggestions are welcome.

[jzohrab]

Hi @ljharb, this is an old issue but I recently started using this package. I'm filtering the tap output in a subsequent script. The script is in this PR for another project: https://github.com/covidatlas/li/pull/73/files

Here's the filtered output of a failure:

    ✖ whatever (fail at: tests/unit/crawler/cache/_cache-namer-test.js:14:5)
    -------------------------------------------------------------------------
      operator: fail
      at: Test.<anonymous> (/Users/jeff/Documents/Projects/li/tests/unit/crawler/cache/_cache-namer-test.js:14:5)
      stack: |-
  Error: whatever
  at Test.<anonymous> (/Users/jeff/Documents/Projects/li/tests/unit/crawler/cache/_cache-namer-test.js:14:5)

Rather than modify this project, and ask ppl to change their tests, perhaps you could offer something like this as a script, and ppl could use it like

"test": "tape tests/**/*-test.js | node tools/clean-tap-output.js | tap-spec"

Note the script also tweaks the tap output (adding "(fail at:" etc.) so that it's better in summaries, but that's not relevant for this.

Cheers! jz

[ljharb]

@jzohrab that seems like a great idea for a separate package :-)

[jzohrab]

@ljharb - published separately on npm, or as part of this project? This proj is great, perhaps it could be included in a subdir here. I'm not a real JS dev and so am not sure what's involved in making/publishing a new package, and it seems like a common enough use case that it could just go here. Thoughts?

[ljharb]

Yes, lots of small separate packages is generally preferable to one large one.

I'm not sure how common it is given that this is the only issue, and you and the OP are the only one who've expressed interest.