Simplifies the testing of UI components by providing an elegant, fluent interface for arranging test setups along with a number of runtime debug/test helpers.
MIT License
40
stars
27
forks
source link
rfc(error): improve timeout error stack trace for waitFor timeouts #92
Edit: I originally posted a gross hacky version but I think I found a passable solution like 15 minutes after posting the pull request and have force pushed that now
Full disclosure, I have no idea if this is a horrible idea or not 🙃
We have a stack of waitFor calls in our tests and while I was stumbling trying to resolve some problematic tests, I was frustrated that the stack trace of the exception was incredibly vague:
Error: Element not found
at Timeout._onTimeout (/Users/tom/src/my-cool-app/node_modules/aurelia-testing/dist/commonjs/wait.js:67:10)
at ontimeout (timers.js:436:11)
at tryOnTimeout (timers.js:300:5)
at listOnTimeout (timers.js:263:5)
at Timer.processTimers (timers.js:223:10)
Even when I used a debugger, it was incredibly difficult to track down which waitFor call was causing me grief. After my solution I got a stack trace that helped my track down the specific failing call:
Error: Element not found
at Object.waitFor (/Users/tom/src/my-cool-app/node_modules/aurelia-testing/dist/commonjs/wait.js:35:22)
at /Users/tom/src/my-cool-app/assets/test/my-cool-component.spec.ts:144:39
at step (/Users/tom/src/my-cool-app/assets/test/my-cool-component.spec.ts:33:23)
at Object.next (/Users/tom/src/my-cool-app/assets/test/my-cool-component.spec.ts:14:53)
at fulfilled (/Users/tom/src/my-cool-app/assets/test/my-cool-component.spec.ts:5:58)
Again, not sure if this is a terrible way to do this (I'm running this in node with js-dom, not sure about other setups?), but I hope it at least starts a conversation - maybe I'm missing something else that's simple?
Edit: I originally posted a gross hacky version but I think I found a passable solution like 15 minutes after posting the pull request and have force pushed that now
Full disclosure, I have no idea if this is a horrible idea or not 🙃
We have a stack of waitFor calls in our tests and while I was stumbling trying to resolve some problematic tests, I was frustrated that the stack trace of the exception was incredibly vague:
Even when I used a debugger, it was incredibly difficult to track down which waitFor call was causing me grief. After my solution I got a stack trace that helped my track down the specific failing call:
Again, not sure if this is a terrible way to do this (I'm running this in node with js-dom, not sure about other setups?), but I hope it at least starts a conversation - maybe I'm missing something else that's simple?