Antwort.

Historisch gesehen traten bei der Zunahme der Anzahl automatisierter Tests in Projekten Probleme auf: Tests wurden verwirrt, überschritten die Zeitlimits für die Ausführung, und es war schwierig zu verstehen, was wofür verantwortlich war. Darüber hinaus wuchs das Risiko von Abhängigkeiten zwischen verschiedenen Teilen des Testsystems und einer Verlangsamung der allgemeinen Pipeline-Leistung.

Das Problem tritt auf, wenn die Anzahl der Tests schneller wächst als die architektonische Unterstützung der Testinfrastruktur gewährt wird. Ohne skalierbare Lösungen werden Tests langsam, schwierig zu warten, die Suche und Lokalisierung von Defekten wird kompliziert, und die technische Schuld wächst schnell.

Die Lösung besteht darin, spezielle Strategien zu implementieren:

Clusterung der Tests nach Modulen und Ebenen (Unit, Integration, E2E) unter Verwendung entsprechender Tags und Filter.
Parallele Ausführung von Tests (Sharding, verteilte Test-Suiten) zur Beschleunigung der Durchführung.
Einsatz des Microservices-Ansatzes in der Testinfrastruktur: standardisierte DSL-Abstraktionen, separate Dienste zur Verwaltung der Testinfrastruktur.
Automatisierung der Erkennung von wiederholenden und veralteten Tests, regelmäßige Refactoring und Auditierung der Abdeckung.

Hauptmerkmale:

Modularität und Wiederverwendbarkeit von Tests und Testbibliotheken.
Vollständige Automatisierung der CI/CD-Integrationen und die Möglichkeit zur automatischen Skalierung der Ressourcen.
Einführung von Tools zur Überwachung der Qualität automatisierter Tests und der Codeabdeckung.

Fangfragen.

Kann man alle Tests nur als Integrationstests schreiben, um mehr Code sofort abzudecken?

Nein, dieser Ansatz verringert die Lokalisierung von Defekten und führt zu hohen Unterstützungskosten sowie einer Verlangsamung der Durchführung von Regressionstests.

Bedeutet Skalierbarkeit von automatisierten Tests nur deren Beschleunigung?

Skalierbarkeit beinhaltet Architektur, Wartbarkeit, Beschleunigung und flexible Infrastruktur. Beschleunigung ist lediglich eine Folge eines gut gestalteten großen Systems.

Wie kann man Tests richtig skalieren, wenn Teams in verschiedenen Zeitzonen arbeiten?

Es ist wichtig, die Möglichkeit eines lokalen Starts und die Unabhängigkeit der Testumgebungen zu berücksichtigen, sonst kommt es zu "Konflikten" zwischen den Aufgaben der Teams.

Typische Fehler und Anti-Patterns

Alle Tests werden in einem Verzeichnis ohne Strukturierung nach Bereichen geschrieben.
Direkte Wiederverwendung von Testdaten („Copy-Paste“ anstelle von Bibliotheken/Fixutren).
Fehlende Überwachung/Metriken zur Ausführungszeit und Stabilität der Tests.

Beispiel aus dem Leben

Negativer Fall

In der Firma gab es sofort mehrere Teams, die neue automatisierte Tests in einen Ordner hinzugefügt haben, ohne ihre Änderungen abzustimmen. Nach einigen Wochen fielen die automatisierten Tests aufgrund von Daten- und Abhängigkeitsinkompatibilitäten aus, die Ausführungszeit überstieg 2 Stunden.

Vorteile:

Niedriger Einstieg für Anfänger.
Schneller Start der Automatisierung.

Nachteile:

Fehlende Skalierbarkeit.
Schwierigkeit bei der Fehlersuche und -analyse.
Verlangsamung der Produkteinführungen.

Positiver Fall

In einem der Teams wurde eine modulare Struktur geschaffen, es wurde getrenntes CI nach Codebereichen eingeführt, die Stabilität erhöht, automatische Alarme über ineffiziente Tests implementiert.