Test stack traces are useless

[brbrr]

After switching to async/await - mocha stack traces become useless since they don't include any useful info except some promise related stack. This makes kinda hard to understand what the problem is.

It would be great to show what code actually failed as it was in sync tests.

I did a quick search, and I find this article: https://www.sitepoint.com/testing-node-applications/#gettingbetterstacktraces

it suggests to use trace & clarify npm modules, which is kinda works since it only includes the step function call, but not an actual internal function call.

  1) [WPCOM] Gutenberg Markdown block: (desktop) @jetpack
       Publish a simple post with Markdown block
         Can start new post:
     TimeoutError: Timed out waiting for element with css selector of '#adminmenumain' to be present and displayed
Wait timed out after 20528ms
      at /Users/brbrr/Developer/a8c/wp-e2e-tests/node_modules/selenium-webdriver/lib/promise.js:2201:17
      at Context.sync (node_modules/mocha-steps/lib/step.js:31:29)
      at Context.<anonymous> (specs-blocks/gutenberg-markdown-block-spec.js:52:32)
      at Context.sync (node_modules/mocha-steps/lib/step.js:29:24)
      at Context.<anonymous> (lib/mocha-hooks.js:125:12)
      at Context.sync (node_modules/mocha-steps/lib/step.js:31:29)
      at Context.<anonymous> (specs-blocks/gutenberg-markdown-block-spec.js:46:55)
      at Context.sync (node_modules/mocha-steps/lib/step.js:29:24)
      at Context.<anonymous> (specs-blocks/gutenberg-markdown-block-spec.js:23:10)
      at Context.<anonymous> (lib/mocha-hooks.js:21:9)
      at Context.<anonymous> (lib/mocha-hooks.js:16:9)

VS

  1) [WPCOM] Gutenberg Markdown block: (desktop) @jetpack
       Publish a simple post with Markdown block
         Can start new post:
     TimeoutError: Timed out waiting for element with css selector of '#adminmenumain' to be present and displayed
Wait timed out after 20263ms
      at /Users/brbrr/Developer/a8c/wp-e2e-tests/node_modules/selenium-webdriver/lib/promise.js:2201:17
      at process._tickCallback (internal/process/next_tick.js:68:7)

[bsessions85]

I looked in to this a little further and I think trace & clarify are as good as it gets for now. Node 12 should be able to handle it better, according to https://github.com/nodejs/node/issues/11865