Hans und Peter durften zum wiederholen Male Vanessa Böhner als Gast begrüßen (zuletzt in Revision 367 dabei, außerdem mit Webseite und Twitter ausgerüstet) und diesmal über alle Formen und Spielarten des (Frontend-) Testings sprechen.
Schaunotizen
- [00:00:52] Frontend-Testing
- Wir quatschen über die tägliche Praxis von Unit Testing, End-To-End-Test, Integration Tests und Snapshot-Tests mit Jest und JSDOM aber auch über Paradigmen wie Test Driven Development und Regressionstests. Den Wert von Tests als Dokumentation stellen wir tatsächlicher Dokumentation und Code-Kommentaren gegenüber. Anhand der Test-Pyramide besprechen wir den Wert unterschiedlicher Testverfahren (z.B. Monkey Testing vs. End-to-End-Tests mit Tools wie Selenium, Cypress und Puppeteer sowie seiner Firefox-Variante), Testing bei Oracle und den zweifelhaften Wert von Test-Coverage. Vanessa empfielt die diversen Werke von Kent C. Dodds als Einstieg in die Welt des JS-Testings. Zum Ende hin streifen wir kurz Visual Regression Testing, ziehen den naheliegenden Vergleich zwischen Softwaretest und Sport und kommen auf das allseits beliebte Thema des Reinregierens von „denen da Oben“ in die Software-Entwicklung zu sprechen.
[00:59:32] Keine Schaunotizen
- ai-driven Podcast
- Die Ankündigung aus Revison 362 ist wahr geworden: Tobias‘ Podcast über KI ist da!
- Veranstaltungen mit Vanessa
- Wer Vanessa live erleben möchte hat dazu in den nächsten Wochen in Hamburg in zweimal in München Gelegenheit!
Kommentare
Lars #
Geschrieben am 13.02.2019 um 00:52
Hi,
hier einige Dinge die ich über das Testing gelernt habe:
– durch Dokumentation mit Code-Beispielen konnte ich bisher auch erschreckend viele „bugs“ finden, da man den Code in der Dokumentation in verständliche Sprache bringt und somit das erwartet Ergebnis mit anderen Augen sieht als wenn man gerade „im“ Code ist
– Tests sollten direkt im Modul bzw. bei der View zu finden sein, nicht ein Verzeichnis welches alle Tests beinhaltet (z.B. https://github.com/voku/Codeception-TestAutomationFramework/tree/master/src/modules/something/example), so dass man beim refactoring nicht auch noch die entsprechenden Tests suchen muss
– Mutation Testing ist viel realitätsnäher als jeder Unit Test und man findet wirklich viele „bugs“ … ggf. zu viele!?
– Visual Regression Tests machen keinen Spaß, auch wenn man diese auf bestimmte HTML-Container einschränken bzw. HTML-Container ausschließen kann (z.B. https://github.com/voku/Codeception-TestAutomationFramework/blob/master/src/modules/something/example/SomethingExamplePageView_Lall_AcceptanceCest.php)
– Acceptance Test sind schnell eingefügt :) einfach alle Views automatisch nacheinander aufrufen ggf. direkt + HTML Validierung (z.B. https://github.com/voku/Codeception-TestAutomationFramework/blob/master/tests/_support/AcceptanceTester.php#L59) durchführen
– in den letzten Monaten habe ich mich zudem viel mit Statischer Code Analyse beschäftigt und konnte sehr viele „bugs“ finden und beheben, welche in Unit Tests nicht auffallen, da diese nur in edge cases auftreten, welche man natürlich nicht testet
– wenn der Kunde nach all dem Testing mit dem IE9 ankommt, welcher natürlich nicht automatisch getestet ist (da Chrome Headless viel einfacher zu automatisieren ist), dann ist die Applikation für den Kunden ggf. trotzdem „kaputt“, daher sollte man eine Art „Error Reporting“ integrieren, welches nicht nur serverseitige Exceptions / Errors / Warnings / Notices sondern auch über JS Fehler berichtet (z.B. eine ausbaufähige Version https://gist.github.com/voku/79cc77eab5da0374092a7a3a09da16c1)
Schepp #
Geschrieben am 20.02.2019 um 07:23
Danke Lars!!
Tobias Oberrauch #
Geschrieben am 18.02.2019 um 13:05
Wow, vielen vielen Dank für die Erwähnung :)
In der neusten Folge geht es um das autonome Fahren: http://aidriven.business/podcast-6-autonomes-fahren/
Gruß Tobias
RSS-Feed zu diesem Beitrag