Show stacktrace on test error in repl

[stephendeyoung]

What has changed?

• Add exception stacktrace to test runner output for tests that failed in error
• Will show the 'Print stacktrace' button in the repl that user can click on to see the full stacktrace

Details

A PR had already been raised for this a few years ago. Given there are git conflicts I thought it was easier to simply create a new PR.

One issue with my current implementation is that if there are multiple errors only the last error will display the 'Print stacktrace' button. Is there a way of having multiple buttons after each test error?

Fixes #424

My Calva PR Checklist

If this PR involves only documentation changes, I have:

• Read Editing Documentation
• Directed this pull request at the published branch.
• Built the site locally (if the changes were more involved than simple typo fixes), and verified that the site is presented as expected.
• Referenced the issue I am fixing/addressing in a commit message for the pull request (if there was is an issue for the documentation change)
  • If I am fixing the issue, I have used GitHub's fixes/closes syntax
  • If I am fixing just part of the issue, I have just referenced it w/o any of the "fixes” keywords.

If this PR involves code changes, I have:

• Read How to Contribute.
• Directed this pull request at the dev branch. (Or have specific reasons to target some other branch.)
• Made sure I have changed the PR base branch, so that it is not published. (Sorry for the nagging.)
• Updated the [Unreleased] entry in CHANGELOG.md, linking the issue(s) that the PR is addressing.
• Figured if anything about the fix warrants tests on Mac/Linux/Windows/Remote/Whatever, and either tested it there if so, or mentioned it in the PR.
• Added to or updated docs in this branch, if appropriate
• Tests
  • Tested the particular change
  • Figured if the change might have some side effects and tested those as well.
  • Smoke tested the extension as such.
  • Tested the VSIX built from the PR (so, after you've submitted the PR). You'll find the artifacts by clicking Show all checks in the CI section of the PR page, and then Details on the ci/circleci: build test.
• Referenced the issue I am fixing/addressing in a commit message for the pull request.
  • If I am fixing the issue, I have used GitHub's fixes/closes syntax
  • If I am fixing just part of the issue, I have just referenced it w/o any of the "fixes” keywords.
• Created the issue I am fixing/addressing, if it was not present.
• Formatted all JavaScript and TypeScript code that was changed. (use the prettier extension or run npm run prettier-format)
• Confirmed that there are no linter warnings or errors (use the eslint extension, run npm run eslint before creating your PR, or run npm run eslint-watch to eslint as you go).

Ping @PEZ, @bpringe, @corasaurus-hex, @Cyrik

[PEZ]

Thanks for doing this! ❤️ The changes look good. I've tested that it works.

ESLint seems unhappy with something. Are you running the main build task when you hack on Calva? It should have a pane where the ESLint results are showing. Let me know if you need any help with this.

[stephendeyoung]

@PEZ I've fixed that now. I will go through the remaining checklist items.

[PEZ]

I think it looks fine. Docs is not strictly necessary here. If you find the time for that you can add it as a separate update. Merging!

[stephendeyoung]

@PEZ thanks for merging this in and releasing it. Currently if more than one test fails the user will only be able to print the stacktrace for the last error that occurs. Is there a way of displaying a button for each test error or is that overkill?

[PEZ]

It's not overkill. It is also not currently prepared for that. But shouldn't be too hard to achieve, I think. Maybe we will need to keep track of the trace objects we have created and free them when a new test run is issued. And maybe not. @bpringe usually can help with that kind of decision.

[PEZ]

Also. It would be great if we tested the feature added by this PR in an integration test. Maybe that's a way to give ourselves the courage to go for the multiple stack-trace buttons.

[bpringe]

Maybe we will need to keep track of the trace objects we have created and free them when a new test run is issued.

That sounds like a good idea to me, if we're going to be savings traces in memory.