Javascript Exceptions sollten die System Tests fehlschlagen lassen
Bisher schlagen die System Tests nicht fehl wenn es Javascript Exceptions gibt die den eigentlichen Workflow nicht behindern.
Der Nachteil ist, dass ein unentdeckter Javascript Fehler dazu führen kann, dass allein durch uptime-monitoring über Nacht etliche Tausend Exceptions in unserern Exception Tracker reportet werden. Da sentry.io im free plan ein Limit bei 5000 Exceptions / Monat hat ist das ziemlich ärgerlich und auch bei einem self-hosted System keine gute Idee.
Aktuell trat das Problem auf (Sentry Exception wird mit !780 (merged) gefixt) und hat unsere monatlichen Exceptions verbraucht:
Blogpost dazu:
https://medium.com/@coorasse/catch-javascript-errors-in-your-system-tests-89c2fe6773b1
Features der Umsetzung in !781 (merged):
- im Teardown eines System-Tests wird die Konsole geprüft:
assert_browser_logs_empty
- man kann innerhalb jedes System-Tests auch selbst
assert_browser_logs_empty
schreiben. Das bietet sich vor allem bei langen tests und vor erwarteten Fehlermeldungen an - man kann Fehlermeldungen explizit erwarten, z.B. so:
expect_console_log_error(message: "Failed to load resource: the server responded with a status of 403 (Forbidden)")
- hierbei wird überprüft, dass genau dieser Fehler genau einmal auftritt. Tritt er nicht oder häufiger auf, ist dies ein Fail.
- die anderen Log-Einträge, die nicht auf die message passen, werden aufgehoben und beim nächsten
assert_browser_logs_empty
verarbeitet (spätestens am Ende des Testscases) Man kann zufällig auftretende Fehler global ignorieren. In der Dateisystem_test_browser_console_helper.rb
ist eine ignore-Liste. Im Moment ist da nur ein Ignore-Fall von “addEventListener of null” drin, der scheinbar zufällig durch tiptap ausgelöst wird, bei mir lokal ca. 1-3x pro kompletten Durchlauf
Edited by Benjamin Bock