End-to-End-Tests bei jedem Build ausführen: ein TeamCity-Beispiel, das mit jedem CI/CD-Werkzeug funktioniert

Warum End-to-End-Tests bei jedem Build laufen sollten

Ein End-to-End-Test bedient Ihre Anwendung so, wie es ein Benutzer tut: er öffnet sie, klickt und tippt sich durch einen ganzen Arbeitsablauf und prüft, was der Bildschirm am Ende zeigt.Es ist der Test, der findet, was Unit-Tests nicht finden können: eine kaputte Schaltfläche, ein Formular, das sich nicht mehr absenden lässt, eine Seite, die ihren Inhalt verloren hat.

Ein End-to-End-Test, der nur läuft, wenn jemand daran denkt, findet diese Probleme spät.Lassen Sie ihn stattdessen bei jeder Änderung laufen, und eine Regression wird Minuten nach dem Push gefunden, solange die Änderung dem Entwickler noch frisch im Kopf ist.

GUI Test Studio bringt genau dafür einen Kommandozeilen-Runner mit: gtr-cli.Er wird mit den Apps installiert.Er führt die aufgenommenen und bearbeiteten End-to-End-GUI-Tests ohne Fenster aus und antwortet so, wie eine Pipeline es erwartet: ein Exit-Code, eine JUnit-Datei, ein Protokoll, das Ihr CI-Werkzeug versteht.

Was Sie brauchen

Schritt 1: Den Build-Rechner vorbereiten

Ein End-to-End-Test spielt Klicks und Eingaben auf einem echten Bildschirm ab, der Build-Agent braucht also einen Desktop.

1. 1

   GUI Test Studio installieren und sich einmal anmelden

   Das Installationsprogramm setzt gtr-cli auf den PATH.Melden Sie sich auf diesem Rechner einmal bei den Apps an, mit dem Konto, unter dem der Agent läuft.

2. 2

   Den Agenten in einer angemeldeten Windows-Sitzung ausführen

   Starten Sie den TeamCity-Agenten aus einer angemeldeten Benutzersitzung, nicht als Windows-Dienst: Ein Dienst hat keinen Bildschirm, auf dem er einen Test wiedergeben könnte.Behalten Sie die Bildschirmgröße und die Skalierung der Aufzeichnung bei.Siehe Den Build-Rechner vorbereiten.

3. 3

   Oder Webtests headless ausführen

   Ein Test einer Web-App kann mit --headless on ganz ohne Browserfenster laufen.Dann braucht er keinen freien Bildschirm, und mehrere Browser und Geräte laufen nebeneinander.

Schritt 2: Den Befehl zusammenstellen

Sie müssen die Optionen nicht lernen.Öffnen Sie in einer der beiden Apps das Fenster „Befehlszeile & CI/CD“, haken Sie an, was Sie möchten, und kopieren Sie den Befehl oder das fertige Snippet für Ihr CI-Tool mit Ihren echten Pfaden.

Vergrößern

Diesen Befehl führt unsere Beispiel-Pipeline aus:

gtr-cli run tests\Checkout\Checkout.GTS --branch all --countdown 0 --format teamcity ^
  --junit ci-out\junit.xml --json ci-out\result.json ^
  --artifacts ci-out\artifacts --bug-report pdf

Jede Option wird in Tests in Ihrer Pipeline ausführen erklärt und von gtr-cli help auf jedem Computer, auf dem GUI Test Studio installiert ist.

Schritt 3: Den Build-Schritt in TeamCity hinzufügen

Erstellen Sie eine Build-Konfiguration für Ihr Repository, fügen Sie einen Build-Schritt hinzu und geben Sie ihm den Befehl.Ein PowerShell-Schritt und ein Command-Line-Schritt funktionieren beide.In unserem Beispiel führt der Schritt ein kleines Skript aus dem Repository aus, das den Shop startet und dann gtr-cli aufruft.

Vergrößern

Fügen Sie einen VCS-Trigger hinzu, damit jeder Push auf jeden Branch einen Build startet.Das ist die ganze Einrichtung: TeamCity braucht kein Plug-in, weil gtr-cli seine Protokollsprache spricht.

Schritt 4: Die Ergebnisse in TeamCity lesen

Pushen Sie eine Änderung und schauen Sie zu.Jeder Browser und jedes Gerät ist ein eigener Test, sodass Sie auf einen Blick sehen, wo er fehlgeschlagen ist.

Vergrößern

Das Build-Protokoll

gtr-cli schreibt eine Zeile pro Schritt und sagt deutlich, was fehlgeschlagen ist: welche Prüfung, auf welchem Browser und Gerät und warum.

Vergrößern

Der fehlgeschlagene Build

Die Übersicht des Builds nennt die fehlgeschlagenen Tests und ihren Grund, ohne dass Sie das Protokoll öffnen müssen.

Vergrößern

Die Tests

Die Registerkarte „Tests“ listet jeden Test des Builds auf.Weil jedes Ergebnis als Test gemeldet wird, verfolgt TeamCity auch seine Historie, seine Dauer und wie oft er fehlgeschlagen ist.

Vergrößern

Die Nachweise

Die Artefakte enthalten alles, was der Lauf gesehen hat: einen Ordner pro Browser und Gerät mit dem Video des Laufs, seinem Bericht und seinem Fehlerbericht, und für jeden Fehlschlag das erwartete und das tatsächliche Bild mit den Änderungen rot umrandet.Öffnen Sie denselben Lauf im GUI Test Runner-Recorder für den vollständigen Konfidenzbericht.

Vergrößern

Jeder Browser und jedes Gerät in einem Build

Ein Webtest kann einmal erstellt und auf mehreren Browsern und Geräten ausgeführt werden: Chrome, Edge und Firefox, Desktops, Smartphones und Tablets.In der Pipeline führt --branch all alle in einem Build aus, und die ohne Fenster laufen nebeneinander.Lesen Sie Jeder Browser und jedes Gerät aus einer einzigen Aufzeichnung.

Kein TeamCity?Derselbe Befehl funktioniert überall

gtr-cli ist an kein Werkzeug gebunden.Es ist ein Programm, das Tests ausführt und einen Exit-Code zurückgibt, also kann alles, was einen Befehl ausführen kann, Ihre End-to-End-Tests ausführen: ein CI-Server, eine geplante Aufgabe, ein Release-Skript.Funktionstests, Regressionstests, Smoke-Tests, Abnahmetests: wie auch immer Sie die Tests nennen, die Ihre Anwendung über ihre Oberfläche bedienen, sie laufen auf dieselbe Weise.

- name: End-to-end tests
  run: gtr-cli run tests --countdown 0 --format github --junit results\junit.xml --artifacts results\artifacts

Wie es weitergeht