Jeder Task wird automatisch getestet, bevor er gemergt werden kann — sowohl mit eng gefassten Unit-Tests als auch mit umfassenderen End-to-End-Tests, die die laufende App ausführen. Die Testing-Ansicht zeigt die Tests eines Projekts unabhängig von einem einzelnen Task.

Testing

Tests in der Task-Detailansicht

In der Detailansicht eines Tasks zeigt der Schritt Test das Ergebnis der Unit-Tests des Projekts (wie viele bestanden, wie viele fehlgeschlagen sind, und die Ausgabe etwaiger Fehler), und der Schritt E2E zeigt das Ergebnis der End-to-End-Szenarien — simulierte Benutzeraktionen in der tatsächlich laufenden Anwendung. Schlägt Test oder E2E fehl, erhält der Schritt Fix die Fehlerdetails, versucht das Problem zu beheben, und die Tests laufen erneut; das kann sich einige Male automatisch wiederholen. Schlagen die Tests nach den erlaubten Versuchen weiterhin fehl, wird der Task failed, und die Fehlerdetails bleiben ihm angehängt.

Die Testing-Ansicht und ihre Tabs

Standardmäßig hat die Testing-Ansicht drei innere Tabs: History — Dashboard, History — Modules und Unit Tests. Weitere Tabs — Setup, Dashboard, Verdicts, E2E Plans, Scenarios, Integration Tests, Release Tests und das E2E Cockpit — sind vorhanden, bleiben aber verborgen, bis sie in der Navigationsanpassung eingeschaltet werden.

Der Tab Unit Tests

Der Tab Unit Tests hat eine Schaltfläche Run unit tests, Summen des letzten Laufs (bestanden, fehlgeschlagen, übersprungen), eine Tabelle Run History (Datum, bestanden, fehlgeschlagen, gesamt, Dauer) und rechts die einzelnen Tests des ausgewählten Laufs mit Filtern wie Passed und Failed. Ein Klick auf einen Lauf in Run History listet dessen Tests auf; mit dem Filter Failed wird der Fehler jedes fehlgeschlagenen Tests gelesen. Ein Lauf, der nicht abgeschlossen wurde, ist mit crashed, dem Grund und einer Schaltfläche Ask AI to fix markiert.

Verify-Urteile

Nach dem Testen prüft der Schritt Verify jedes Akzeptanzkriterium des Tasks erneut und hält eines von drei Urteilen fest:

• passed — die Prüfung lief und entsprach dem Erwarteten.
• failed — die Prüfung lief und entsprach nicht; die Ausgabe nennt, was ausgeführt wurde, was erwartet wurde und was zurückkam.
• unverifiable — die Prüfung konnte gar nicht ausgeführt werden (zum Beispiel, weil sie eine laufende Instanz braucht, die nicht verfügbar ist). Das lässt den Task nie fehlschlagen; der Punkt wird als ausstehende manuelle Verifizierung aufgeführt.

Build & Start/Stop

Es lässt sich ein Build des Projekts auslösen und anschließend eine laufende Instanz davon auf einem eigenen dedizierten Port starten oder stoppen — unabhängig von den isolierten Instanzen, die die Pipeline während eines Tasks für das E2E-Testen hochfährt.

Live-Status und Terminal-Ausgabe

Auf einen Blick ist erkennbar, ob die Instanz läuft, gebaut wird oder gestoppt ist, und ihre Terminal-/Konsolenausgabe lässt sich live mitverfolgen — nützlich, um zu bestätigen, dass ein Build erfolgreich war, oder um zu diagnostizieren, warum nicht.

Einen laufenden Testlauf stoppen

Eine lang laufende Unit-Test-Suite lässt sich jederzeit direkt aus der Testing-Ansicht stoppen, ohne auf ihr Ende zu warten. Wird der AITM-Server neu gestartet, während ein Testlauf läuft, wird der Lauf sicher unterbrochen — er bleibt beim nächsten Start nicht im Zustand "running" hängen; der Server erkennt und bereinigt das.

Kombiniertes CPU-/RAM-Budget für Tests

Unit-Tests und E2E-Tests teilen sich ein gemeinsames CPU- und Speicherbudget, das sich automatisch an die Größe des Servers anpasst, auf dem AITM läuft. Tests laufen nacheinander, sodass ihr kombinierter Ressourcenverbrauch den Host nie überlastet — das schützt vor Abstürzen, die durch das gleichzeitige Ausführen mehrerer Test-Workloads entstehen.

E2E-Urteilsverlauf

Jeder für dieses Projekt aufgezeichnete End-to-End-Testlauf wird im Tab Verdicts (standardmäßig verborgen) aufbewahrt, mit seinem Urteil (pass, feature bug, environment error usw.) und einer Zeitleiste, in der sich zurückblättern lässt, um zu sehen, wie sich die Testgesundheit im Lauf der Zeit entwickelt hat.

Dropdown der Bug-Anzeige

Das Dropdown der Bug-Anzeige in der oberen Leiste zeigt höchstens die 10 neuesten Bugs, sodass es auch bei Projekten mit langer Bug-Historie schnell und lesbar bleibt. Es zeigt immer einen Link Open Bug Section — auch wenn die Liste der neuesten Einträge leer ist —, sodass das Dropdown nie in einer Sackgasse endet; die vollständige Bug-Liste ist unabhängig von der Anzahl neuer Einträge immer einen Klick entfernt.