Bewährte Methoden zum Testen in CodeCatalyst

Wenn Sie die von bereitgestellten Testfunktionen verwenden CodeCatalyst, empfehlen wir Ihnen, diese bewährten Methoden zu befolgen.

Automatische Erkennung

Bei der Konfiguration von Aktionen in CodeCatalyst können Sie mit der automatischen Erkennung automatisch die Ausgaben verschiedener Tools, wie z. B. JUnit-Testberichte, ermitteln und daraus relevante CodeCatalyst Berichte generieren. Durch die automatische Erkennung wird sichergestellt, dass weiterhin Berichte generiert werden, auch wenn sich die Namen oder Pfade zu den erkannten Ergebnissen ändern. Wenn neue Dateien hinzugefügt werden, werden diese CodeCatalyst automatisch erkannt und relevante Berichte erstellt. Wenn Sie jedoch die automatische Erkennung verwenden, ist es wichtig, einige der folgenden Aspekte dieser Funktion zu berücksichtigen:

• Wenn Sie in Ihrer Aktion die automatische Erkennung aktivieren, weisen alle automatisch erkannten Berichte desselben Typs dieselben Erfolgskriterien auf. Beispielsweise würden gemeinsame Kriterien wie die Mindestbestehensquote für alle automatisch erkannten Testberichte gelten. Wenn Sie unterschiedliche Kriterien für Berichte desselben Typs benötigen, müssen Sie jeden dieser Berichte explizit konfigurieren.

• Mit der automatischen Erkennung können auch Berichte gefunden werden, die von Ihren Abhängigkeiten erstellt wurden. Wenn Erfolgskriterien konfiguriert sind, schlägt die Aktion für diese Berichte möglicherweise fehl. Dieses Problem kann durch eine Aktualisierung der Konfiguration für den Ausschlusspfad behoben werden.

• Es kann nicht garantiert werden, dass bei der automatischen Erkennung jedes Mal dieselbe Berichtsliste erstellt wird, da die Aktion zur Laufzeit gescannt wird. Wenn Sie möchten, dass ein bestimmter Bericht immer erstellt wird, sollten Sie Berichte explizit konfigurieren. Wenn beispielsweise Tests im Rahmen Ihres Builds nicht mehr ausgeführt werden, würde das Testframework keine Ausgaben erzeugen und folglich würde kein Testbericht erstellt werden, und die Aktion könnte erfolgreich sein. Wenn Sie möchten, dass der Erfolg Ihrer Aktion von diesem speziellen Test abhängt, müssen Sie diesen Bericht explizit konfigurieren.

Tipp

Wenn Sie mit einem neuen oder vorhandenen Projekt beginnen, verwenden Sie die automatische Erkennung für das gesamte Projektverzeichnis (einschließlich**/*). Dadurch wird die Berichtsgenerierung für alle Dateien in Ihrem Projekt aufgerufen, einschließlich der Dateien in Unterverzeichnissen.

Weitere Informationen finden Sie unter Konfiguration von Qualitätsberichten in einer Aktion.

Erfolgskriterien

Sie können Qualitätsgrenzwerte für Ihre Berichte durchsetzen, indem Sie Erfolgskriterien konfigurieren. Wenn beispielsweise zwei Codeabdeckungsberichte automatisch erkannt wurden, einer mit einer Leitungsabdeckung von 80% und der andere mit einer Leitungsabdeckung von 60%, haben Sie die folgenden Optionen:

• Legen Sie die Erfolgskriterien für die automatische Erkennung für die Leitungsabdeckung auf 80% fest. Dies würde dazu führen, dass der erste Bericht erfolgreich und der zweite Bericht fehlschlägt, was dazu führen würde, dass die gesamte Aktion fehlschlägt. Um den Workflow zu entsperren, fügen Sie Ihrem Projekt neue Tests hinzu, bis die Zeilenabdeckung für den zweiten Bericht 80% überschreitet.

• Legen Sie die Erfolgskriterien für die automatische Erkennung für die Leitungsabdeckung auf 60% fest. Dies würde dazu führen, dass beide Berichte erfolgreich sind, was dazu führen würde, dass die Aktion erfolgreich wäre. Sie könnten dann daran arbeiten, die Codeabdeckung im zweiten Bericht zu erhöhen. Mit diesem Ansatz können Sie jedoch nicht garantieren, dass der Erfassungsgrad im ersten Bericht nicht unter 80% fällt.

• Konfigurieren Sie einen oder beide Berichte explizit, indem Sie den visuellen Editor verwenden oder für jeden Bericht einen expliziten YAML-Abschnitt und -Pfad hinzufügen. Auf diese Weise könnten Sie separate Erfolgskriterien und benutzerdefinierte Namen für jeden Bericht konfigurieren. Bei diesem Ansatz könnte die Aktion jedoch fehlschlagen, wenn sich die Berichtspfade ändern.

Weitere Informationen finden Sie unter Erfolgskriterien für Berichte konfigurieren.

Pfade einschließen/ausschließen

Bei der Überprüfung der Aktionsergebnisse können Sie die Liste der Berichte, die generiert werden, anpassen, CodeCatalyst indem Sie und konfigurierenIncludePaths. ExcludePaths

• Geben IncludePaths Sie hier die Dateien und Dateipfade CodeCatalyst an, die Sie bei der Suche nach Berichten berücksichtigen möchten. Wenn Sie beispielsweise angeben, dass das gesamte Build-Image"/test/report/*", das von der Aktion verwendet wurde, nach dem /test/report/ Verzeichnis CodeCatalyst durchsucht wird, durchsucht wird. Wenn das Verzeichnis gefunden CodeCatalyst wird, wird in diesem Verzeichnis nach Berichten gesucht.

  Anmerkung

  Bei manuell konfigurierten Berichten IncludePaths muss es sich um ein Glob-Muster handeln, das einer einzelnen Datei entspricht.

• Geben ExcludePaths Sie hier die Dateien und Dateipfade an, die Sie bei der Suche nach Berichten ausschließen möchten CodeCatalyst . Wenn Sie beispielsweise angeben"/test/reports/**/*", CodeCatalyst wird nicht nach Dateien im /test/reports/ Verzeichnis gesucht. Um alle Dateien in einem Verzeichnis zu ignorieren, verwenden Sie das **/* Glob-Muster.

Im Folgenden finden Sie Beispiele für mögliche Glob-Muster.

Muster	Beschreibung
*.*	Entspricht allen Objektnamen im aktuellen Verzeichnis, die einen Punkt enthalten
*.xml	Entspricht allen Objektnamen im aktuellen Verzeichnis, die mit enden .xml
*.{xml,txt}	Entspricht allen Objektnamen im aktuellen Verzeichnis, die mit .xml oder enden .txt
**/*.xml	Entspricht Objektnamen in allen Verzeichnissen, die mit enden .xml
testFolder	Entspricht einem testFolder aufgerufenen Objekt und behandelt es als Datei
testFolder/*	Entspricht Objekten auf einer Ebene des Unterordners vontestFolder, z. B. testFolder/file.xml
testFolder/*/*	Entspricht Objekten auf zwei Ebenen des Unterordners vontestFolder, z. B. testFolder/reportsFolder/file.xml
testFolder/**	Entspricht dem Unterordner testFolder und Dateien unter testFolder, wie z. B. testFolder/file.xml und testFolder/otherFolder/file.xml

CodeCatalyst interpretiert die Glob-Muster wie folgt:

• Der Schrägstrich (/) trennt Verzeichnisse in Dateipfaden.

• Das Sternchen (*) entspricht einem oder mehreren Zeichen einer Namenskomponente ohne Überschreiten der Ordnergrenzen.

• Ein doppeltes Sternchen (**) steht für null oder mehr Zeichen einer Namenskomponente in allen Verzeichnissen.

Anmerkung

ExcludePathshat Vorrang vor. IncludePaths Wenn beide IncludePaths den gleichen Ordner ExcludePaths enthalten, wird dieser Ordner nicht nach Berichten durchsucht.