Add ability to track browser errors #72
Conversation
csutter
force-pushed
the
js-error-tracking
branch
from
0046238 to
512e937
Compare
A recent incident on Finder Frontend saw the filters on search pages malfunctioning due to an error loading an asset file (which hadn't been uploaded correctly). We could write a specific e2e test exercising the filters, but ideally this functionality should already be tested extensively in the app's own integration/system tests. Instead, this adds a helper to enhance a test suite by keeping track of console errors, Javascript exceptions, and network issues, which should be able to catch many sources of unexpected failures in our frontend code. - Add `trackBrowserErrors` helper library - Use `trackBrowserErrors` in the Finder Frontend e2e tests to begin with (possibly with a view to other apps opting in to this behaviour too)
csutter
force-pushed
the
js-error-tracking
branch
from
512e937 to
d6c350e
Compare
Yeah - I've intentionally added it to Finder Frontend only for now, because we probably would want to check whether any apps for obscure legacy reasons might have JS errors/tech debt that we're aware of. 👍 |
There was a problem hiding this comment.
Looks great, well done working this out so quickly.
I guess the thing that is a bit concerning is if there's any external resources that could lead to an alert or not as they could be annoying. It's a shame we don't know for sure if Smokey had roughly the same functionality (I think it did) as that'd be reason to be confident.
| }); | ||
| }; | ||
|
|
||
| export { trackBrowserErrors }; |
There was a problem hiding this comment.
I'd wonder whether this file should be unit tested? I guess we've not got anything of substance in the lib directory already to warrant it so probably a lack of precedent.
|
|
||
| test.describe("Finder frontend", { tag: ["@app-finder-frontend"] }, () => { | ||
| trackBrowserErrors(test); |
There was a problem hiding this comment.
Do we know of a way we can apply this to everything? I guess the equivalent of a beforeEach for everything in the suite?
There is setup files - an example is the auth.setup.js -perhaps those type of files offer a hook to do a global beforeEach.
|
Thanks @csutter for looking at this!
Why not have this as a E2E/smoke test? Sounds like important user functionality that would be good to validate. We really shouldn't have assertions for testing non-user functionality. They aren't testing what we actually care about. Testing JS/console failures have in the past been a source of flakey-ness and don't always correlate broken user functionality. |
|
@csutter wondering if you're still working on this or can this PR be closed? |
A recent incident on Finder Frontend saw the filters on search pages malfunctioning due to an error loading an asset file (which hadn't been uploaded correctly). We could write a specific e2e test exercising the filters, but ideally this functionality should already be tested extensively in the app's own integration/system tests.
Instead, this adds a helper to enhance a test suite by keeping track of console errors, Javascript exceptions, and network issues, which should be able to catch many sources of unexpected failures in our frontend code.
trackBrowserErrorshelper librarytrackBrowserErrorsin the Finder Frontend e2e tests to begin with (possibly with a view to other apps opting in to this behaviour too)In the browser console
As part of the Playwright test