Antwort.

Eine sorgfältige Versionierung und Integration von Automatisierungstests ist entscheidend, um sicherzustellen, dass die Überprüfung dem aktuellen Stand des Projekts entspricht.

Geschichte der Fragestellung

Automatisierungstests wurden anfangs oft separat vom Hauptprojekt geführt, was zu Inkompatibilitäten und Wartungsproblemen führte. Die Entwicklung mehrerer Branches, häufige Software- und Testveröffentlichungen — erforderten ein gemeinsames Versionskontrollsystem.

Problem

Ohne Versionierung und abgestimmte Integration entstehen:

Ausführung von veralteten Tests auf geänderter Software
"Fehler" in Tests bei der Einführung neuer Funktionen, die Änderungen in den Tests nicht berücksichtigen
Ausfälle in CI/CD

Lösung

Ein moderner Ansatz:

Tests werden in einem gemeinsamen Versionskontrollsystem gespeichert (meist git)
Verknüpfung des Testbranches mit dem Softwareentwicklungsbranch: im Feature-Branch — werden Tests und Code gemeinsam entwickelt
Automatische Überprüfungen/Bauten werden bei Pull-Requests durchgeführt
Überprüfung und Abstimmung von Änderungen in Tests und Code

# Allgemeiner Ansatz:
git checkout -b feature/new_login
# Funktion und Tests werden gemeinsam entwickelt und getestet
# Nach der Überprüfung werden sie gemeinsam in den Hauptbranch gemergt

Wichtige Merkmale:

Konsistenz der Code- und Teständerungen (keine Entsynchronisation)
Bequeme Rückgängigmachung und Versionsabgleich (über git history)
Möglichkeit der Teamarbeit und Code-Review von Automatisierungstests

Fangfragen.

Können Tests in einem separaten (vom Projektcode) Repository gespeichert werden?

Ja, aber dann wird es schwieriger, die Aktualität der Tests zu gewährleisten, man benötigt manuelle Synchronisierung und es besteht das Risiko, bei der Veröffentlichung oder Bugfixierung etwas "zu vergessen" zu aktualisieren.

Müssen die Tests sofort die gesamte neue Funktionalität bei der Erstellung eines PR abdecken?

Idealerweise — ja, praktisch decken sie häufig die MVP/Hauptezenarien im ersten PR ab, während komplexere Fälle als separate Aufgaben behandelt werden. Wichtig ist, dass die kritische Funktionalität sofort abgedeckt ist.

Kann man nur die Teständerungen ohne Code-Rückgängigmachung zurücksetzen?

Wenn Tests und Code in demselben Branch sind — ja, man kann Revisionen zurücksetzen. Aber es ist besser, "Rücksetzern" von Tests ohne Code zu vermeiden: das verschlechtert die Qualität der Überprüfung.

Typische Fehler und Antipatterns

Speicherung von Tests nicht in git, sondern in Dateisystemen
Durchführung von Tests in einem separaten Repository ohne klare Verbindung zum Projekt
Zufügen von Tests von außen (post factum), anstatt gleichzeitig mit dem Code

Beispiel aus dem Leben

Negativer Fall

Projekt mit separatem Repository für Automatisierungstests. Nach der Veröffentlichung haben die Programmierer "vergessen", die Tests zu aktualisieren — die Tests fielen aus, es wurden veraltete Überprüfungen durchgeführt, Bugs wurden in Produktion gefunden.

Vorteile:

Programmierer konnten unabhängig von QA arbeiten

Nachteile:

Zeitverlust durch Synchronisation, Vorhandensein von "veralteten" Tests

Positiver Fall

Tests und Projektcode werden im selben git-Branch geführt: Bei jedem neuen Pull Request werden die Automatisierungstests für den hinzugefügten Code unbedingt aktualisiert. Alle Änderungen durchlaufen Code-Review und automatische Überprüfungen.