> For the complete documentation index, see [llms.txt](https://docs.aqua-cloud.io/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aqua-cloud.io/documentation/de-documentation/automatisierung/rest-api/junit-xml-integration-in-aqua.md). # 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.aqua-cloud.io/documentation/de-documentation/automatisierung/rest-api/junit-xml-integration-in-aqua.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.