# JUnit-XML-Integration in aqua Automatisieren Sie das Ausführen lokaler/Unit-Tests über die Erstellung von JUnit-XML-Dateien bis hin zur Integration in aqua als gruppierte Testausführungen (Testszenario) mit erfolgreich/fehlgeschlagenen Ergebnissen, um eine CI/CD-Sichtbarkeit zu ermöglichen. ## High-Level Flow {% stepper %} {% step %} ### Entwickler schreiben Tests Die Entwickler schreiben/pflegen Tests (CodeceptJS / Playwright) und verwendet dabei Namenskonventionen mit eingebetteten aqua-IDs. {% endstep %} {% step %} ### Tests ausführen Tests werden (lokal oder in GitLab CI) ausgeführt und erzeugen dabei eine JUnit-XML-Datei `output/result.xml`. {% endstep %} {% step %} ### Artefakt erfassen GitLab CI erfasst das XML als Artefakt und optional einen JUnit-Bericht. {% endstep %} {% step %} ### Veröffentlichung/Import Die Veröffentlichung führt einen Importer aus, der Folgendes tut: * Authentifizierung bei aqua (AQUA\_URL, AQUA\_USER, AQUA\_PASSWORD) * Parsen der JUnit XML * Extrahieren der aqua Test-Szenario-IDs (TS…) und Testfall-IDs (TC…) * Gruppieren der Testfälle nach Szenario-IDs * Durchführung eines REST API-Aufrufs pro Szenario zur Erstellung von Ausführungen und Ergebnissen * Beendet mit dem entsprechenden Statuscode, damit die Pipeline als bestanden oder fehlgeschlagen markiert werden kann {% endstep %} {% endstepper %} ## Konventionen Verwenden Sie IDs innerhalb der Testsuite/Testnamen, damit sie analysiert werden können: * Szenario (Suite/Klassenname/Titel) Präfix: `TS` (z.B. `TS1132748 - GitHub`) * Testfall (einzelner Test) Präfix: `TC` (z.B. `TC1132533 - Lade die GitHub-Startseite`) Regex-Muster: * Szenario-ID: `/(TS\d+)/` * Fall-ID: `/(TC\d+)/` Wenn eine ID fehlt, behandeln Sie diesen Test als ungültig (Richtlinie: Importfehler oder Überspringen—konfigurierbar). ## Generieren von JUnit XML (CodeceptJS + mocha-junitreporter) Typisches Skript (bereits konfiguriert): ```yaml npm ci npx playwright install --with-deps npm run test # Produces output/result.xml ``` Stellen Sie sicher, dass `codecept.conf.ts` eine Mocha-Reporter-Konfiguration enthält, die auf `output/result.xml` verweist (z. B. über `mocha-junit-reporter`). ## Struktur der GitLab CI/CD-Pipeline (.gitlab-ci.yml) Stufen (empfohlen): ```yaml stages: - test - upload ``` Beispiel für die Testphase: ```yaml execute_tests: stage: test image: node:20 script: - npm ci - npx playwright install --with-deps - npm run test artifacts: when: always expire_in: 1 week paths: - output/ reports: junit: output/result.xml ``` Hochladen/Importieren: Beispielstufe ```yaml upload_to_aqua: stage: upload image: mcr.microsoft.com/powershell dependencies: [execute_tests] script: - pwsh ./upload.ps1 ``` (Alternativ verwenden Sie ein .NET-Bild / eine benutzerdefinierte Importer-Binärdatei, falls erforderlich.) ## Umgebungsvariablen (CI/CD) Einstellungen in GitLab → Einstellungen → CI/CD → Variablen (maskiert & geschützt nach Bedarf): * AQUA\_URL (z. B. `https://workshop.aqua-cloud.io/aquaWebNG`) * AQUA\_USER * AQUA\_PASSWORD * Optional`REPORT_FILE` (Standard`./output/result.xml`) ## Importpflichten (Detailliert) Für jeden Durchlauf: 1. JUnit XML lesen `(REPORT_FILE)`. 2. Authentifizieren: POST Token-Endpoint → Bearer-Token erhalten. 3. ` / `-Knoten parsen. 4. Für jedes ``:\ a. Szenario-ID extrahieren (in `classname` oder Parent-Suite-Namen suchen).\ b. Case-ID extrahieren (in `name` suchen).\ c. Status bestimmen:\ i. Bestanden: Fehlen von `` und ``.\ ii. Fehlgeschlagen: Vorhandensein von `` oder `` (Nachricht + Stack erfassen, falls vorhanden). 5. Testfälle per Szenario-ID gruppieren (alle mit gleichem TS... zusammen). 6. Pro Szenario JSON-Payload bauen, die alle enthaltenen Ausführungen enthält. 7. POST an aqua Project / Execution-Endpoint (je ein Aufruf pro Szenario). 8. Fehlgeschlagene POSTs verfolgen. 9. Mit entsprechendem Code beenden (siehe unten). ## Beenden-Codes (vorgeschlagene Zuordnung) Code — Bedeutung * 0 —Erfolg (alle Szenarien gepostet) * 2 — Authentifizierungsfehler * 3 — Netzwerk / Endpunkt nicht erreichbar * 4 — Teilweiser Ausfall (einige Szenarien sind fehlgeschlagen) * 5 — Ungültiges oder unlesbares XML * 6 — Eingabefehler: Fehlende erforderliche IDs / Validierungsfehler * 7 —Unerwartete interne Ausnahme CI schlägt fehl, wenn der Exit-Code != 0 ist (Standardverhalten in GitLab), was möglicherweise die Pipeline zum Fehlschlagen bringt. ## JUnit XML Beispiel ```xml ``` ## Troubleshooting
Leer result.xml Symptom: Leere `result.xml`\ Wahrscheinliche Ursache: Tests wurden nicht ausgeführt oder Reporter falsch konfiguriert\ Aktion: Erneut mit `--verbose` ausführen, Reporter-Konfiguration überprüfen
401 Unauthorized Symptom: 401 Unauthorized\ Wahrscheinliche Ursache: Ungültige Anmeldedaten oder URL\ Aktion: Überprüfen Sie Umgebungsvariablen und Token-Endpunktpfad
Missing IDs error Symptom: Fehlende IDs Fehler\ Wahrscheinliche Ursache: Testnamen folgen nicht der Konvention\ Aktion: Tests umbenennen, um TS / TC-Präfixe einzuschließen
Partial posting Symptom: Teilweises Posten\ Wahrscheinliche Ursache: Netzwerk/API intermittierend\ Aktion: Wiederholungslogik oder Exit-Code 4 markieren
Pipeline green but no data in Aqua Symptom: Pipeline grün, aber keine Daten in Aqua\ Wahrscheinliche Ursache: Importphase übersprungen\ Aktion: Sicherstellen, dass Phase nicht `when: manual` ist und Abhängigkeiten korrekt sind
## Zusammenfassung Diese Konfiguration gewährleistet die Nachverfolgbarkeit zwischen automatisierten Testausführung und in aqua verwalteten Testszenarien/-fällen, indem IDs in Testnamen eingebettet werden. Sie erzeugt standardmäßige JUnit-XML und wandelt diese in strukturierte aqua-Ausführungen innerhalb der CI/CD-Pipeline um, mit robusten Exit-Codes, die den Pipeline-Ausgang steuern.