Skip to content
Artwork for Software Testing & Qualität - Testautomatisierung, KI & Agilität
Software Testing & Qualität - Testautomatisierung, KI & Agilität · Yesterday · 21 min

Frontend-Testing: Echter Browser statt jsdom - Alexander Opalic

Mehr Anforderungen, mehr Pixel: warum Tests im Frontend schwerer sind als im Backend Frontend-Testing ist komplizierter als Backend-Testing, sagt Alexander Opalic, und mit ihm spreche ich darüber, warum er seine Komponenten im echten Browser testet statt in jsdom oder happy-dom. Mit dem Vitest Browser Mode rendert er Datepicker, Tabellen und Modals isoliert in einem iFrame und prüft sie so, wie ein Nutzer sie bedient. Dabei fällt auf, was eine emulierte Umgebung nicht sieht, etwa grauer Text auf weißem Grund, den niemand lesen kann. Der Preis: Ein Klick dauert statt 20 vielleicht 200 Millisekunden, aus fünf Minuten Testlauf werden fünfeinhalb. Wir reden auch über Screenshot-Tests für die eigene Core-UI-Library und über die Frage, wo Visual Regression flaky wird. „Ich finde Frontend-Testing ist komplizierter als Backend-Testing.“ - Alexander Opalic Alexander Opalic ist Full-Stack-Entwickler mit über acht Jahren Erfahrung und arbeitet bei Otto Payments. Auf alexop.dev schreibt er über moderne Webentwicklung, TypeScript, AI Agents und die Zukunft der Softwareentwicklung. Als Speaker beschäftigt er sich besonders mit neuen Developer-Workflows, Testing und der Frage, wie AI verändert, wie wir Software bauen. Highlights: Alexander Opalic hält Frontend-Testing für komplizierter als Backend-Testing, weil eine Komponente neben ihrem Verhalten auch Accessibility und Visual Regression als Anforderungen mitbringt. Der Vitest Browser Mode rendert jede Komponente isoliert in einem iFrame eines echten Browsers, während jsdom und happy-dom den Browser in Node nur emulieren und oft Mocks brauchen. Farbkontraste lassen sich mit jsdom nicht automatisch prüfen, im echten Browser fällt grauer Text auf weißem Grund sofort als Accessibility-Problem auf. Ein Klick dauert im echten Browser etwa 200 Millisekunden und mit jsdom etwa 20, eine Testsuite von fünf Minuten braucht damit rund eine halbe Minute länger. Screenshot-Tests lohnen sich für die Core-UI-Library mit allen Button- und Modal-Varianten, für jede einzelne Webseite werden sie dagegen schnell flaky. Weitere Links zur Episode: Alexander Opalic auf GitHub Alexander Opalic auf X Alexander Opalic auf Bluesky Blog alexop.dev Vitest Browser Mode: Dokumentation Der Talk als Blogpost: What should a green test prove? Blogpost: My first time at tacon 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen Danke an die Community-Partner des Podcasts:

0:00-21:29

transcript

No transcript — this publisher did not publish one.

show notes

Mehr Anforderungen, mehr Pixel: warum Tests im Frontend schwerer sind als im Backend

Frontend-Testing ist komplizierter als Backend-Testing, sagt Alexander Opalic, und mit ihm spreche ich darüber, warum er seine Komponenten im echten Browser testet statt in jsdom oder happy-dom. Mit dem Vitest Browser Mode rendert er Datepicker, Tabellen und Modals isoliert in einem iFrame und prüft sie so, wie ein Nutzer sie bedient. Dabei fällt auf, was eine emulierte Umgebung nicht sieht, etwa grauer Text auf weißem Grund, den niemand lesen kann. Der Preis: Ein Klick dauert statt 20 vielleicht 200 Millisekunden, aus fünf Minuten Testlauf werden fünfeinhalb. Wir reden auch über Screenshot-Tests für die eigene Core-UI-Library und über die Frage, wo Visual Regression flaky wird.

„Ich finde Frontend-Testing ist komplizierter als Backend-Testing.“ - Alexander Opalic

Alexander Opalic ist Full-Stack-Entwickler mit über acht Jahren Erfahrung und arbeitet bei Otto Payments. Auf alexop.dev schreibt er über moderne Webentwicklung, TypeScript, AI Agents und die Zukunft der Softwareentwicklung. Als Speaker beschäftigt er sich besonders mit neuen Developer-Workflows, Testing und der Frage, wie AI verändert, wie wir Software bauen.

Highlights:

  • Alexander Opalic hält Frontend-Testing für komplizierter als Backend-Testing, weil eine Komponente neben ihrem Verhalten auch Accessibility und Visual Regression als Anforderungen mitbringt.
  • Der Vitest Browser Mode rendert jede Komponente isoliert in einem iFrame eines echten Browsers, während jsdom und happy-dom den Browser in Node nur emulieren und oft Mocks brauchen.
  • Farbkontraste lassen sich mit jsdom nicht automatisch prüfen, im echten Browser fällt grauer Text auf weißem Grund sofort als Accessibility-Problem auf.
  • Ein Klick dauert im echten Browser etwa 200 Millisekunden und mit jsdom etwa 20, eine Testsuite von fünf Minuten braucht damit rund eine halbe Minute länger.
  • Screenshot-Tests lohnen sich für die Core-UI-Library mit allen Button- und Modal-Varianten, für jede einzelne Webseite werden sie dagegen schnell flaky.

Weitere Links zur Episode:

📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen

Danke an die Community-Partner des Podcasts:

links9