Back

Testing

Strategien und Werkzeuge für automatisierte Tests und Qualitätssicherung.

title: "Frontend Testing" slug: "testing" category: "Engineering" description: "Testpyramide, Unit- bis E2E-Tests und Tools wie Vitest, Testing Library und Playwright." tags: ["Unit Tests", "E2E", "Playwright", "Vitest", "Testing Library", "a11y"] navigation_path: "/tiles/testing"

Frontend Testing

Ein solides Setup für automatisierte Tests ist im modernen Frontend-Engineering unerlässlich. Es erhöht das Vertrauen in Refactorings, dokumentiert Edge-Cases und sichert die Qualität vor jedem Release. Ein typisches Frontend-Projekt strukturiert Tests als Testpyramide:

  • Unit Tests: Testen isolierte Funktionen, Hooks oder einzelne, reine UI-Komponenten. (Tools: Vite/Vitest, Jest)
  • Integration Tests: Prüfen das Zusammenspiel mehrerer Komponenten, oft inklusive State-Management und gemockten API-Aufrufen. (Tools: React Testing Library)
  • E2E (End-to-End) Tests: Simulieren echte Benutzerinteraktionen im realen Browser gegen einen vollständig laufenden Stack. (Tools: Playwright, Cypress)
  • Visual Regression Tests: Erkennen unbeabsichtigte Layout- und Design-Änderungen auf Pixel-Ebene. (Tools: Chromatic, Percy)
  • Accessibility (a11y) Tests: Sichern die Barrierefreiheit für Screenreader und Tastaturnavigation. (Tools: axe-core)
Testing Playground
$ vitest run components

Warum überhaupt testen?

  • Confidence: Entwickler:innen trauen sich, Legacy-Code aufzuräumen und Dependencies zu aktualisieren, weil Tests sie vor Regressionen schützen.
  • Dokumentation: Ein gut geschriebener Test (it('should show error when field is empty')) erklärt das erwartete Verhalten der Anwendung oftmals besser als ein Kommentar.
  • Design: Testgetriebene Entwicklung (TDD) oder zumindest test-bewusstes Architektur-Design führt oft zu entkoppelten, modulareren Systemen.

Worauf ist zu achten?

  1. Nicht Implementierungsdetails testen! Teste, was der Anwender sieht und tut (z.B. Button-Klick, Text-Anzeige), nicht wie die internen States (setState) genau heißen. (Vgl. Philosophie der React Testing Library).
  2. Speed is King: Unit Tests müssen in Millisekunden laufen. Wenn die Testsuite Minuten dauert, führen Teams sie lokal nicht mehr aus.
  3. Flakiness vermeiden: Flaky Tests (Tests, die manchmal grün, mal rot sind – oft durch Timeouts, Animationen oder asynchrone Race Conditions bedingt) zerstören das Vertrauen in die Testsuite und zwingen das Team, Tests zu ignorieren.
  4. Mocking bedacht einsetzen: Mocks sind nützlich, aber je mehr du um deine Komponenten herum mockst, desto weniger testest du das tatsächliche Verhalten im Browser.