Seite 12 - Testing/E2E

Pinia Stores isoliert zu testen erfordert mehr als nur einen Store zu instanziieren und eine Action aufzurufen. Zwischen createPinia und createTestingPinia, echten und gemockten Actions sowie Store-übergreifenden Abhängigkeiten liegen Entscheidungen, die über Aussagekraft und Wartbarkeit einer gesamten Testsuite entscheiden.

Ein separates Dokument, das den Zweck und die Struktur einer Testsuite beschreibt, wirkt im Moment seiner Entstehung hilfreich, veraltet aber in der Praxis fast zwangsläufig innerhalb weniger Monate, sobald sich der beschriebene Testcode weiterentwickelt, während das Dokument selbst unverändert stehen bleibt. Die wirkungsvollste Form von Testdokumentation ist deshalb nicht ein separates, gesondert gepflegtes Dokument, sondern der Testcode selbst, sofern er so geschrieben wird, dass er seine eigene Absicht ohne zusätzliche Erklärung offenlegt.

Component Testing mit Cypress schließt die Lücke zwischen isolierten Unit-Tests und langsamen End-to-End-Läufen. Vue-Komponenten werden dabei tatsächlich im Browser gemountet, mit echtem DOM, echten Events und kontrollierbaren Netzwerkaufrufen, ohne die gesamte Anwendung hochfahren zu müssen.

Wer in Unit-Tests einfach globalThis.fetch überschreibt, baut fragile Mocks, die bei jeder Code-Änderung neu angepasst werden müssen. Mock Service Worker fängt Netzwerk-Requests stattdessen auf HTTP-Ebene ab, testet den echten Fetch-Aufruf und lässt sich für Erfolgs- wie Fehlerfälle präzise konfigurieren, ohne den Anwendungscode selbst zu verändern.

Wer eine bats-Testsuite fuer Bash-Skripte hat, weiss noch lange nicht, welche Zeilen tatsaechlich ausgefuehrt wurden. Code Coverage mit kcov schliesst diese Luecke, zeigt Zeile fuer Zeile, was Tests wirklich abdecken, und macht ungetestete Fehlerpfade sichtbar, lange bevor sie in Produktion zum Problem werden.

Ein Penetration Test deckt reale Angriffspfade auf, die automatisierte Scanner übersehen, erfordert aber vorab eine schriftliche Freigabe, einen klaren Scope und ein Team, das die Ergebnisse tatsächlich umsetzt. Dieser Artikel erklärt Testansätze, Autorisierungspflichten, die Vorbereitung von Entwickler-Teams und den Unterschied zwischen internem Security Review und externem Pentest anhand konkreter Praxisbeispiele.

KI-generierter Code sieht oft überzeugend fertig aus, enthält aber häufig subtile Fehler bei Randfällen, veraltete API-Aufrufe oder übersehene Sicherheitslücken, die ein Reviewer ohne gezielten Blick leicht durchwinkt. Dieser Artikel zeigt typische Fehlermuster von KI-Assistenten und liefert eine praktische Checkliste, mit der Entwickler KI-generierte Änderungen genauso gründlich prüfen wie menschlich geschriebenen Code.

Self-Healing-Tests versprechen, dass ein durch eine harmlose Layoutänderung gebrochener Selector automatisch erkannt und durch eine passende Alternative ersetzt wird, ohne dass ein Mensch den Testcode manüll anpassen muss. Dieses Versprechen klingt verlockend angesichts der bekannten Wartungslast brüchiger E2E-Tests, verdeckt aber ein grundlegendes Missverständnis darüber, was ein Selector eigentlich tut und wo automatische Heuristiken an ihre fachlichen Grenzen stoßen, sobald sich nicht nur die Struktur, sondern die tatsächliche Bedeutung eines Elements verändert.

Progressive Web Apps bringen Service Worker, Offline Fallbacks und Install Prompts mit, die klassische E2E Tests nicht abdecken. Wer Cypress oder Playwright ohne eigene Strategie für Netzwerksimulation, Cache Invalidierung und Manifest Validierung einsetzt, übersieht genau die Fehler, die Kunden offline oder nach einem Deploy mit veralteten Preisen konfrontieren. Dieser Artikel zeigt, wie PWA Testing in der Praxis zuverlässig funktioniert.

Composables mocken ist in Vue-Tests komplizierter als es zunächst wirkt, weil Composables oft globalen Zustand, Netzwerkzugriffe und reaktive Nebenwirkungen kombinieren. Mit vi.mock, gezielter Dependency Injection und provide/inject als Testing-Seam lassen sich Komponenten trotzdem zuverlässig isoliert testen, ohne echte Composable-Implementierungen mitzuschleppen.