Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Führen Sie parallel Tests in Batch-Builds aus
Sie können es verwenden AWS CodeBuild , um parallel Tests in Batch-Builds auszuführen. Die parallele Testausführung ist ein Testansatz, bei dem mehrere Testfälle gleichzeitig in verschiedenen Umgebungen, Computern oder Browsern ausgeführt werden, anstatt sequentiell ausgeführt zu werden. Dieser Ansatz kann die Gesamtdauer der Testausführung erheblich reduzieren und die Testeffizienz verbessern. CodeBuildIn können Sie Ihre Tests auf mehrere Umgebungen aufteilen und gleichzeitig ausführen.
Zu den wichtigsten Vorteilen der parallel Testausführung gehören:
1. **Verkürzte Ausführungszeit** — Tests, die nacheinander Stunden dauern würden, können innerhalb von Minuten abgeschlossen werden.
1. **Bessere Ressourcennutzung — Nutzt** die verfügbaren Computerressourcen effizient.
1. **Früheres Feedback** — Schnellerer Abschluss des Tests bedeutet schnelleres Feedback an Entwickler.
1. **Kostengünstig** — Spart auf lange Sicht sowohl Zeit als auch Rechenkosten.
Bei der Implementierung der parallel Testausführung werden üblicherweise zwei Hauptansätze in Betracht gezogen: separate Umgebungen und Multithreading. Beide Methoden zielen zwar auf eine gleichzeitige Testausführung ab, unterscheiden sich jedoch erheblich in ihrer Implementierung und Effektivität. Separate Umgebungen erzeugen isolierte Instanzen, in denen jede Testsuite unabhängig ausgeführt wird, während Multithreading mehrere Tests gleichzeitig innerhalb desselben Prozessraums unter Verwendung verschiedener Threads ausführt.
Zu den wichtigsten Vorteilen separater Umgebungen gegenüber Multithreading gehören:
1. **Isolierung** — Jeder Test wird in einer vollständig isolierten Umgebung ausgeführt, wodurch Interferenzen zwischen den Tests vermieden werden.
1. **Ressourcenkonflikte** — Keine Konkurrenz um gemeinsam genutzte Ressourcen, wie sie beim Multithreading häufig auftritt.
1. **Stabilität** — Weniger anfällig für Rennbedingungen und Synchronisationsprobleme.
1. **Einfacheres Debuggen** — Wenn Tests fehlschlagen, ist es einfacher, die Ursache zu identifizieren, da jede Umgebung unabhängig ist.
1. **Statusverwaltung** — Probleme mit gemeinsam genutzten Zuständen, die Multithread-Tests betreffen, lassen sich mühelos verwalten.
1. **Bessere Skalierbarkeit** — Es können problemlos weitere Umgebungen ohne Komplexität hinzugefügt werden.
**Topics**
+ [Support in AWS CodeBuild](#parallel-test-support)
+ [parallel Testausführung in Batch-Builds aktivieren](parallel-test-enable.md)
+ [Verwenden Sie den `codebuild-tests-run` CLI-Befehl](parallel-test-tests-run.md)
+ [Verwenden Sie den `codebuild-glob-search` CLI-Befehl](parallel-test-glob-search.md)
+ [Über das Aufteilen von Tests](parallel-test-splitting.md)
+ [Führen Sie einzelne Build-Berichte automatisch zusammen](parallel-test-auto-merge.md)
+ [Beispiel für parallele Testausführung für verschiedene Testframeworks](sample-parallel-test.md)
## Support in AWS CodeBuild
AWS CodeBuild bietet robuste Unterstützung für die parallel Testausführung durch seine Batch-Build-Funktion, die speziell für die Ausführung in separaten Umgebungen entwickelt wurde. Diese Implementierung passt perfekt zu den Vorteilen isolierter Testumgebungen.
**Batch-Build mit Testverteilung**
CodeBuildDie Batch-Build-Funktionalität ermöglicht die Erstellung mehrerer Build-Umgebungen, die gleichzeitig ausgeführt werden. Jede Umgebung arbeitet als vollständig isolierte Einheit mit eigenen Rechenressourcen, eigener Laufzeitumgebung und Abhängigkeiten. Über die Batch-Build-Konfiguration können Sie angeben, wie viele parallel Umgebungen sie benötigen und wie die Tests auf sie verteilt werden sollen.
**Testen Sie Sharding CLI**
CodeBuild enthält über sein CLI-Tool einen integrierten Testverteilungsmechanismus`codebuild-tests-run`, der Tests automatisch in verschiedene Umgebungen unterteilt.
**Aggregation von Berichten**
Eine der wichtigsten Stärken der Implementierung CodeBuild ist die Fähigkeit, die Aggregation von Testergebnissen nahtlos zu handhaben. Tests werden zwar in separaten Umgebungen ausgeführt, sammelt aber CodeBuild automatisch die Testberichte aus jeder Umgebung und kombiniert sie zu einem einheitlichen Testbericht auf Batch-Build-Ebene. Diese Konsolidierung bietet einen umfassenden Überblick über die Testergebnisse und behält gleichzeitig die Effizienzvorteile der parallel Ausführung bei.
Das folgende Diagramm erklärt das vollständige Konzept der parallel Testausführung in AWS CodeBuild.
![\[Konzeptdiagramm der parallel Testausführung.\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/images/parallel-test.png)
# parallel Testausführung in Batch-Builds aktivieren
Um Tests parallel auszuführen, aktualisieren Sie die Batch-Build-Buildspec-Datei so, dass sie das Build-Fanout-Feld und die Anzahl der parallel Builds enthält, um die Testsuite in dem Feld aufzuteilen, wie unten gezeigt. `parallelism` Das `parallelism` Feld gibt an, wie viele unabhängige Executoren eingerichtet sind, um die Testsuite auszuführen.
Um die Tests in mehreren parallel Ausführungsumgebungen auszuführen, setzen Sie das `parallelism` Feld auf einen Wert größer als Null. Im Beispiel unten `parallelism` ist es auf fünf gesetzt, was bedeutet, dass fünf identische Builds CodeBuild gestartet werden, die einen Teil der Testsuite parallel ausführen.
Sie können den [codebuild-tests-run](parallel-test-tests-run.md)CLI-Befehl verwenden, um Ihre Tests aufzuteilen und auszuführen. Ihre Testdateien werden aufgeteilt und ein Teil Ihrer Tests wird in jedem Build ausgeführt. Dies reduziert die Gesamtzeit, die für die Ausführung der gesamten Testsuite benötigt wird. Im folgenden Beispiel werden die Tests in fünf Teile aufgeteilt und die Teilungspunkte werden anhand des Namens der Tests berechnet.
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 5
ignore-failure: false
phases:
install:
commands:
- npm install jest-junit --save-dev
pre_build:
commands:
- echo 'prebuild'
build:
commands:
- |
codebuild-tests-run \
--test-command 'npx jest --runInBand --coverage' \
--files-search "codebuild-glob-search '**/_tests_/**/*.test.js'" \
--sharding-strategy 'equal-distribution'
post_build:
commands:
- codebuild-glob-search '**/*.xml'
- echo "Running post-build steps..."
- echo "Build completed on `date`"
reports:
test-reports:
files:
- '**/junit.xml'
base-directory: .
discard-paths: yes
file-format: JUNITXML
```
Wenn Berichte für Build-Fanout-Build konfiguriert sind, werden die Testberichte für jeden Build separat generiert. Diese können auf der Registerkarte **Berichte** der entsprechenden Builds in der Konsole eingesehen werden. AWS CodeBuild
Weitere Hinweise zur Ausführung parallel Tests im Batch finden Sie unter[Beispiel für parallele Testausführung für verschiedene Testframeworks](sample-parallel-test.md).
# Verwenden Sie den `codebuild-tests-run` CLI-Befehl
AWS CodeBuild stellt CLI bereit, die den Testbefehl und den Speicherort der Testdatei als Eingabe verwendet. Die CLI mit diesen Eingaben teilt die Tests in eine Anzahl von Shards auf, wie im `parallelism` Feld angegeben, basierend auf den Testdateinamen. Die Zuweisung der Testdateien zum Shard wird durch die Sharding-Strategie entschieden.
```
codebuild-tests-run \
--files-search "codebuild-glob-search '**/__tests__/*.js'" \
--test-command 'npx jest --runInBand --coverage' \
--sharding-strategy 'equal-distribution'
```
In der folgenden Tabelle werden die Felder für den `codebuild-tests-run` CLI-Befehl beschrieben.
| Feldname | Typ | Erforderlich oder optional | Definition |
| --- | --- | --- | --- |
| `test-command` | Zeichenfolge | Erforderlich | Dieser Befehl wird zum Ausführen der Tests verwendet. |
| `files-search` | Zeichenfolge | Erforderlich | Dieser Befehl gibt eine Liste von Testdateien. Sie können den AWS CodeBuild bereitgestellten [codebuild-glob-search](parallel-test-glob-search.md)CLI-Befehl oder ein anderes Dateisuchtool Ihrer Wahl verwenden. Stellen Sie sicher, dass der `files-search` Befehl Dateinamen ausgibt, die jeweils durch eine neue Zeile getrennt sind. |
| `sharding-strategy` | Enum | Optional | Zulässige Werte: `equal-distribution` (Standard), `stability` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codebuild/latest/userguide/parallel-test-tests-run.html) Weitere Informationen finden Sie unter [Über das Aufteilen von Tests](parallel-test-splitting.md). |
Die `codebuild-tests-run` CLI identifiziert zunächst die Liste der Testdateien mithilfe des im `files-search` Parameter angegebenen Befehls. Anschließend bestimmt sie unter Verwendung der angegebenen Sharding-Strategie eine Teilmenge von Testdateien, die für den aktuellen Shard (Umgebung) bestimmt sind. Schließlich wird diese Teilmenge von Testdateien in eine durch Leerzeichen getrennte Liste formatiert und vor der Ausführung an das Ende des im Parameter angegebenen Befehls angehängt. `test-command`
Für Testframeworks, die keine durch Leerzeichen getrennten Listen akzeptieren, bietet die `codebuild-tests-run` CLI über die `CODEBUILD_CURRENT_SHARD_FILES` Umgebungsvariable eine flexible Alternative. Diese Variable enthält eine durch Zeilenumbrüche getrennte Liste von Testdateipfaden, die für den aktuellen Build-Shard bestimmt sind. Durch die Nutzung dieser Umgebungsvariablen können Sie sich leicht an verschiedene Anforderungen des Test-Frameworks anpassen und dabei auch diejenigen berücksichtigen, die Eingabeformate erwarten, die sich von durch Leerzeichen getrennten Listen unterscheiden. Darüber hinaus können Sie die Namen der Testdateien auch gemäß den Anforderungen des Testframeworks formatieren. Das Folgende ist ein Beispiel für die Verwendung von `CODEBUILD_CURRENT_SHARD_FILES` unter Linux mit dem Django-Framework. Hier `CODEBUILD_CURRENT_SHARD_FILES` wird verwendet, um Dateipfade in *Punktnotation* abzurufen, die von Django unterstützt werden:
```
codebuild-tests-run \
—files-search "codebuild-glob-search '/tests/test_.py'" \
—test-command 'python3 manage.py test $(echo "$CODEBUILD_CURRENT_SHARD_FILES" | sed -E "s/\//__/g; s/\.py$//; s/__/./g")' \
—sharding-strategy 'equal-distribution'
```
**Anmerkung**
Beachten Sie, dass die `CODEBUILD_CURRENT_SHARD_FILES` Umgebungsvariable nur innerhalb des Bereichs der `codebuild-tests-run` CLI verwendet werden kann.
Wenn Sie den Befehl `CODEBUILD_CURRENT_SHARD_FILES` inside test-command verwenden, setzen Sie ihn außerdem `CODEBUILD_CURRENT_SHARD_FILES` in doppelte Anführungszeichen, wie im obigen Beispiel gezeigt.
# Verwenden Sie den `codebuild-glob-search` CLI-Befehl
AWS CodeBuild bietet ein integriertes CLI-Tool namens`codebuild-glob-search`, mit dem Sie auf der Grundlage eines oder mehrerer Glob-Muster nach Dateien in Ihrem Arbeitsverzeichnis suchen können. Dieses Tool kann besonders nützlich sein, wenn Sie Tests für bestimmte Dateien oder Verzeichnisse in Ihrem Projekt ausführen möchten.
## Usage
Die `codebuild-glob-search` CLI hat die folgende Verwendungssyntax:
```
codebuild-glob-search [ ...]
```
+ ````, usw.: Ein oder mehrere Glob-Muster, die mit den Dateien in Ihrem Arbeitsverzeichnis abgeglichen werden sollen.
+ `*`: Entspricht einer beliebigen Zeichenfolge (mit Ausnahme von Pfadtrennzeichen).
+ `**`: Entspricht einer beliebigen Zeichenfolge (einschließlich Pfadtrennzeichen).
**Anmerkung**
Stellen Sie sicher, dass die globale Zeichenfolge Anführungszeichen enthält. Verwenden Sie den Befehl, um die Ergebnisse des Mustervergleichs zu überprüfen. `echo`
```
version: 0.2
phases:
build:
commands:
- echo $(codebuild-glob-search '**/__tests__/*.js')
- codebuild-glob-search '**/__tests__/*.js' | xargs -n 1 echo
```
## Ausgabe
Die CLI gibt eine durch Zeilenumbrüche getrennte Liste von Dateipfaden aus, die den angegebenen Glob-Mustern entsprechen. Die zurückgegebenen Dateipfade sind relativ zum Arbeitsverzeichnis.
Wenn keine Dateien gefunden werden, die den angegebenen Mustern entsprechen, gibt die CLI eine Meldung aus, dass keine Dateien gefunden wurden.
Beachten Sie, dass Verzeichnisse, die aufgrund eines bestimmten Musters gefunden wurden, von den Suchergebnissen ausgeschlossen werden.
## Beispiel
Wenn Sie nur nach Dateien im Testverzeichnis und seinen Unterverzeichnissen mit einer `.js` Erweiterung suchen möchten, können Sie den folgenden Befehl mit der `codebuild-glob-search` CLI verwenden:
```
codebuild-glob-search '**/__tests__/*.js'
```
Dieser Befehl sucht nach allen Dateien mit einer `.js` Erweiterung innerhalb des `__tests__` Verzeichnisses und seiner Unterverzeichnisse, wie im Muster angegeben.
# Über das Aufteilen von Tests
AWS CodeBuild Mit der Funktion zum Aufteilen von Tests können Sie die Ausführung Ihrer Testsuite auf mehrere Recheninstanzen parallelisieren und so die gesamte Testlaufzeit reduzieren. Diese Funktion wird über die Batch-Konfiguration in Ihren CodeBuild Projekteinstellungen und das `codebuild-tests-run` Hilfsprogramm in Ihrer Buildspec-Datei aktiviert.
Die Tests werden auf der Grundlage der angegebenen Sharding-Strategie aufgeteilt. CodeBuild bietet zwei Sharding-Strategien, wie unten beschrieben:
Gleichmäßige Verteilung
Die `equal-distribution` Sharding-Strategie unterteilt die Tests auf der Grundlage der alphabetischen Reihenfolge der Testdateinamen auf parallel Builds. Bei diesem Ansatz werden zuerst die Testdateien sortiert und dann mithilfe einer Methode verteilt, die auf Blöcken basiert. Dabei wird sichergestellt, dass ähnliche Dateien zu Testzwecken gruppiert werden. Es wird empfohlen, wenn es sich um einen relativ kleinen Satz von Testdateien handelt. Diese Methode zielt zwar darauf ab, jedem Shard ungefähr die gleiche Anzahl von Dateien zuzuweisen, mit einem maximalen Unterschied von eins, garantiert jedoch keine Stabilität. Wenn Testdateien in nachfolgenden Builds hinzugefügt oder entfernt werden, kann sich die Verteilung vorhandener Dateien ändern, was möglicherweise zu einer Neuzuweisung zwischen den Shards führen kann.
Stabilität
Die `stability` Sharding-Strategie verwendet einen konsistenten Hashing-Algorithmus, um Tests auf mehrere Shards aufzuteilen und so sicherzustellen, dass die Dateiverteilung stabil bleibt. Wenn neue Dateien hinzugefügt oder entfernt werden, stellt dieser Ansatz sicher, dass die vorhandenen file-to-shard Zuweisungen weitgehend unverändert bleiben. Für große Testsuiten wird empfohlen, die Stabilitätsoption zu verwenden, um die Tests gleichmäßig auf die Shards zu verteilen. Dieser Mechanismus zielt auf eine nahezu gleichmäßige Verteilung ab und stellt sicher, dass jeder Shard eine ähnliche Anzahl von Dateien mit nur minimaler Varianz erhält. Die Stabilitätsstrategie garantiert zwar keine ideale Gleichverteilung, bietet aber eine nahezu gleichmäßige Verteilung, wodurch die Konsistenz der Dateizuweisungen zwischen den Builds gewahrt bleibt, auch wenn Dateien hinzugefügt oder entfernt werden.
Um das Testsplitting zu aktivieren, müssen Sie den Batch-Bereich in Ihren CodeBuild Projekteinstellungen konfigurieren und dabei die gewünschte `parallelism` Stufe und andere relevante Parameter angeben. Darüber hinaus müssen Sie das `codebuild-tests-run` Hilfsprogramm zusammen mit den entsprechenden Testbefehlen und der Aufteilungsmethode in Ihre Buildspec-Datei aufnehmen.
# Führen Sie einzelne Build-Berichte automatisch zusammen
AWS CodeBuild Unterstützt bei Fanout-Batch-Builds das automatische Zusammenführen einzelner Build-Berichte zu einem konsolidierten Bericht auf Batch-Ebene. Diese Funktion bietet einen umfassenden Überblick über die Testergebnisse und die Codeabdeckung für alle Builds innerhalb eines Batches.
## Funktionsweise
Bei der Ausführung von `fanout` Batch-Builds generiert jeder einzelne Build [Testberichte](test-reporting.md). CodeBuild konsolidiert dann automatisch identische Berichte aus verschiedenen Builds zu einem einheitlichen Bericht, der an den Batch-Build angehängt wird. Diese konsolidierten Berichte sind über das [ BatchGetBuildBatches](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_BatchGetBuildBatches.html#CodeBuild-BatchGetBuildBatches-response-buildBatches)`reportArns`API-Feld leicht zugänglich und können auch auf der Registerkarte „**Berichte**“ der Konsole eingesehen werden. Diese Zusammenführungsfunktion erstreckt sich auch auf automatisch erkannte Berichte.
Konsolidierte Berichte werden unter [Berichtsgruppen](test-report-group.md) erstellt, die entweder in der Buildspec angegeben sind oder von automatisch erkannt werden. CodeBuild Sie können die Trends der zusammengeführten Berichte direkt unter diesen Berichtsgruppen analysieren und so wertvolle Einblicke in die allgemeine Build-Performance und Qualitätskennzahlen für historische Builds desselben Build-Batch-Projekts gewinnen.
Für jeden einzelnen Build innerhalb des Batches CodeBuild werden automatisch separate Berichtsgruppen erstellt. Diese folgen einer bestimmten Benennungskonvention und kombinieren den Namen der Batch-Build-Berichtsgruppe mit dem Suffix von`BuildFanoutShard`, wobei das `shard_number` für die Nummer des Shards steht, in dem die Berichtsgruppe erstellt wurde. Diese Organisation ermöglicht es Ihnen, Trends sowohl auf konsolidierter als auch auf individueller Build-Ebene zu verfolgen und zu analysieren, sodass Sie die Build-Prozesse flexibel überwachen und bewerten können.
Der Batch-Build-Bericht folgt derselben Struktur wie die [einzelnen Build-Berichte](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Report.html). Die folgenden Schlüsselfelder auf der Registerkarte „**Bericht**“ sind spezifisch für Batch-Build-Berichte:
**Status des Batch-Build-Berichts**
Der Status von Batch-Build-Berichten folgt je nach Berichtstyp bestimmten Regeln:
+ Testberichte:
+ Erfolgreich: Der Status wird auf erfolgreich gesetzt, wenn alle einzelnen Build-Berichte erfolgreich waren.
+ Fehlgeschlagen: Der Status wird auf „Fehlgeschlagen“ gesetzt, wenn ein einzelner Build-Bericht fehlgeschlagen ist.
+ Unvollständig: Der Status wird als unvollständig markiert, wenn ein einzelner Build-Bericht fehlt oder einen unvollständigen Status hat.
+ Berichte zur Codeabdeckung:
+ Vollständig: Der Status wird auf abgeschlossen gesetzt, wenn alle einzelnen Build-Berichte abgeschlossen sind.
+ Fehlgeschlagen: Der Status wird auf „Fehlgeschlagen“ gesetzt, wenn ein einzelner Build-Bericht fehlgeschlagen ist.
+ Unvollständig: Der Status wird als unvollständig markiert, wenn ein einzelner Build-Bericht fehlt oder einen unvollständigen Status hat.
**Zusammenfassung des Tests**
Der zusammengeführte Testbericht konsolidiert die folgenden Felder aus allen einzelnen Build-Berichten:
+ duration-in-nano-seconds: Maximale Testdauer in Nanosekunden für alle einzelnen Build-Berichte.
+ total: Die kombinierte Anzahl aller Testfälle, summiert die Gesamtzahl der Tests aus jedem Build.
+ Statusanzahl: Bietet eine konsolidierte Ansicht der Teststatuswerte wie „bestanden“, „Fehlgeschlagen“ oder „Übersprungen“, die berechnet werden, indem die Anzahl der einzelnen Statustypen für alle einzelnen Builds aggregiert wird.
**Zusammenfassung der Codeabdeckung**
Der zusammengeführte Bericht zur Codeabdeckung kombiniert Felder aus allen einzelnen Builds anhand der folgenden Berechnungen:
+ abgedeckte Branchen: Summe aller abgedeckten Branchen aus einzelnen Berichten.
+ Fehlende Filialen: Summe aller verpassten Filialen aus einzelnen Berichten.
+ branch-coverage-percentage: `(Total covered branches / Total branches) * 100`
+ abgedeckte Zeilen: Summe aller abgedeckten Zeilen aus einzelnen Berichten.
+ verpasste Zeilen: Summe aller verpassten Zeilen aus einzelnen Berichten.
+ lines-coverage-percentage: `(Total covered lines / Total lines) * 100`
**Ausführungs-ID**
Der Batch-Build-ARN.
**Testfälle**
Der zusammengeführte Bericht enthält eine konsolidierte Liste aller Testfälle aus einzelnen Builds, auf die sowohl über die [DescribeTestCases](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_DescribeTestCases.html)API als auch über den Batch-Build-Bericht in der Konsole zugegriffen werden kann.
**Geltungsbereiche des Codes**
Der zusammengeführte Codeabdeckungsbericht enthält konsolidierte Informationen zur Abdeckung von Leitungen und Filialen für jede Datei in allen einzelnen Builds, auf die sowohl über die [DescribeCodeCoverages](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_DescribeCodeCoverages.html)API als auch über den Batch-Build-Bericht in der Konsole zugegriffen werden kann. Hinweis: Für Dateien, die von mehreren Testdateien abgedeckt werden, die auf verschiedene Shards verteilt sind, verwendet der zusammengeführte Bericht die folgenden Auswahlkriterien:
1. Die Primärauswahl basiert auf der höchsten Linienabdeckung unter den Shards.
1. Wenn die Linienabdeckung bei mehreren Shards gleich ist, wird der Shard mit der höchsten Zweigabdeckung ausgewählt.
# Beispiel für parallele Testausführung für verschiedene Testframeworks
Sie können den `codebuild-tests-run` CLI-Befehl verwenden, um Ihre Tests auf parallel Ausführungsumgebungen aufzuteilen und auszuführen. Der folgende Abschnitt enthält `buildspec.yml` Beispiele für verschiedene Frameworks, die die Verwendung des `codebuild-tests-run` Befehls veranschaulichen.
+ Jedes der folgenden Beispiele umfasst eine `parallelism` Stufe von fünf, was bedeutet, dass fünf identische Ausführungsumgebungen erstellt werden, auf die Sie Ihre Tests verteilen können. Sie können eine `parallelism` Stufe auswählen, die zu Ihrem Projekt passt, indem Sie den `parallelism` Wert im `build-fanout` Abschnitt ändern.
+ Jedes Beispiel unten zeigt, wie Sie Ihre Tests so konfigurieren, dass sie nach dem Namen der Testdatei aufgeteilt werden, was standardmäßig der Fall ist. Dadurch werden die Tests gleichmäßig auf die parallel Ausführungsumgebungen verteilt.
Bevor Sie beginnen, finden Sie [Führen Sie parallel Tests in Batch-Builds aus](parallel-test.md) weitere Informationen unter.
Eine vollständige Liste der Optionen bei der Verwendung des `codebuild-tests-run` CLI-Befehls finden Sie unter[Verwenden Sie den `codebuild-tests-run` CLI-Befehl](parallel-test-tests-run.md).
**Topics**
+ [Konfigurieren Sie parallel Tests mit Django](sample-parallel-test-django.md)
+ [Konfigurieren Sie parallel Tests mit Elixir](sample-parallel-test-elixir.md)
+ [parallel Tests mit Go konfigurieren](sample-parallel-test-go.md)
+ [parallel Tests mit Java (Maven) konfigurieren](sample-parallel-test-java-maven.md)
+ [parallel Tests mit Javascript konfigurieren (Jest)](sample-parallel-test-javascript.md)
+ [Konfigurieren Sie parallel Tests mit Kotlin](sample-parallel-test-kotlin.md)
+ [Konfigurieren Sie parallel Tests mit PHPUnit](sample-parallel-test-phpunit.md)
+ [Konfigurieren Sie parallel Tests mit Pytest](sample-parallel-test-python.md)
+ [Konfigurieren Sie parallel Tests mit Ruby (Cucumber)](sample-parallel-test-ruby-cucumber.md)
+ [parallel Tests mit Ruby (RSpec) konfigurieren](sample-parallel-test-ruby.md)
# Konfigurieren Sie parallel Tests mit Django
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung mit Django auf einer Ubuntu-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 5
phases:
install:
commands:
- echo 'Installing Python dependencies'
- sudo yum install -y python3 python3-pip
- python3 -m ensurepip --upgrade
- python3 -m pip install django
pre_build:
commands:
- echo 'Prebuild'
build:
commands:
- echo 'Running Django Tests'
- |
codebuild-tests-run \
--test-command 'python3 manage.py test $(echo "$CODEBUILD_CURRENT_SHARD_FILES" | sed -E "s/\//__/g; s/\.py$//; s/__/./g")' \
--files-search "codebuild-glob-search '**/tests/*test_*.py'" \
--sharding-strategy 'equal-distribution'
post_build:
commands:
- echo 'Test execution completed'
```
Das obige Beispiel zeigt die Verwendung der Umgebungsvariablen`CODEBUILD_CURRENT_SHARD_FILES`. `CODEBUILD_CURRENT_SHARD_FILES`Wird verwendet, um Dateipfade mit Punktnotation abzurufen, die von Django unterstützt werden. Verwenden Sie doppelte Anführungszeichen `CODEBUILD_CURRENT_SHARD_FILES` innerhalb von Anführungszeichen, wie oben gezeigt.
# Konfigurieren Sie parallel Tests mit Elixir
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung mit Elixir auf einer Ubuntu-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 5
phases:
install:
commands:
- echo 'Installing Elixir dependencies'
- sudo apt update
- sudo DEBIAN_FRONTEND=noninteractive apt install -y elixir
- elixir --version
- mix --version
pre_build:
commands:
- echo 'Prebuild'
build:
commands:
- echo 'Running Elixir Tests'
- |
codebuild-tests-run \
--test-command 'mix test' \
--files-search "codebuild-glob-search '**/test/**/*_test.exs'" \
--sharding-strategy 'equal-distribution'
post_build:
commands:
- echo "Test execution completed"
```
# parallel Tests mit Go konfigurieren
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung mit Go auf einer Linux-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 5
ignore-failure: false
phases:
install:
commands:
- echo 'Fetching Go version'
- go version
pre_build:
commands:
- echo 'prebuild'
build:
commands:
- echo 'Running go Tests'
- go mod init calculator
- cd calc
- |
codebuild-tests-run \
--test-command "go test -v calculator.go" \
--files-search "codebuild-glob-search '**/*test.go'"
post_build:
commands:
- echo "Test execution completed"
```
Im obigen Beispiel enthält die `calculator.go` Funktion einfache mathematische Funktionen zum Testen und alle Testdateien und `calculator.go` Dateien befinden sich im `calc` Ordner.
# parallel Tests mit Java (Maven) konfigurieren
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung mit Java auf einer Linux-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 5
ignore-failure: false
phases:
pre_build:
commands:
- echo 'prebuild'
build:
commands:
- echo "Running mvn test"
- |
codebuild-tests-run \
--test-command 'mvn test -Dtest=$(echo "$CODEBUILD_CURRENT_SHARD_FILES" | sed "s|src/test/java/||g; s/\.java//g; s|/|.|g; s/ /,/g" | tr "\n" "," | sed "s/,$//")' \
--files-search "codebuild-glob-search '**/test/**/*.java'"
post_build:
commands:
- echo "Running post-build steps..."
- echo "Test execution completed"
```
Im angegebenen Beispiel `CODEBUILD_CURRENT_SHARD_FILES` enthält die Umgebungsvariable Testdateien im aktuellen Shard, getrennt durch Zeilenumbrüche. Diese Dateien werden in eine durch Kommas getrennte Liste von Klassennamen in dem Format konvertiert, das vom Parameter für Maven akzeptiert wird. `-Dtest`
# parallel Tests mit Javascript konfigurieren (Jest)
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung mit Javascript auf einer Ubuntu-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: true
build-fanout:
parallelism: 5
ignore-failure: false
phases:
install:
commands:
- echo 'Installing Node.js dependencies'
- apt-get update
- apt-get install -y nodejs
- npm install
- npm install --save-dev jest-junit
pre_build:
commands:
- echo 'prebuild'
build:
commands:
- echo 'Running JavaScript Tests'
- |
codebuild-tests-run \
--test-command "npx jest" \
--files-search "codebuild-glob-search '**/test/**/*.test.js'" \
--sharding-strategy 'stability'
post_build:
commands:
- echo 'Test execution completed'
```
# Konfigurieren Sie parallel Tests mit Kotlin
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung mit Kotlin auf einer Linux-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 2
ignore-failure: false
phases:
install:
runtime-versions:
java: corretto11
commands:
- echo 'Installing dependencies'
- KOTLIN_VERSION="1.8.20" # Replace with your desired version
- curl -o kotlin-compiler.zip -L "https://github.com/JetBrains/kotlin/releases/download/v${KOTLIN_VERSION}/kotlin-compiler-${KOTLIN_VERSION}.zip"
- unzip kotlin-compiler.zip -d /usr/local
- export PATH=$PATH:/usr/local/kotlinc/bin
- kotlin -version
- curl -O https://repo1.maven.org/maven2/org/junit/platform/junit-platform-console-standalone/1.8.2/junit-platform-console-standalone-1.8.2.jar
pre_build:
commands:
- echo 'prebuild'
build:
commands:
- echo 'Running Kotlin Tests'
- |
codebuild-tests-run \
--test-command 'kotlinc src/main/kotlin/*.kt $(echo "$CODEBUILD_CURRENT_SHARD_FILES" | tr "\n" " ") -d classes -cp junit-platform-console-standalone-1.8.2.jar' \
--files-search "codebuild-glob-search 'src/test/kotlin/*.kt'"
- |
codebuild-tests-run \
--test-command '
java -jar junit-platform-console-standalone-1.8.2.jar --class-path classes \
$(for file in $CODEBUILD_CURRENT_SHARD_FILES; do
class_name=$(basename "$file" .kt)
echo "--select-class $class_name"
done)
' \
--files-search "codebuild-glob-search 'src/test/kotlin/*.kt'"
post_build:
commands:
- echo "Test execution completed"
```
Im obigen Beispiel wird die `codebuild-tests-run` CLI zweimal verwendet. Während des ersten Laufs kompiliert Kotlinc die Dateien. Die `CODEBUILD_CURRENT_SHARD_FILES` Variable ruft die dem aktuellen Shard zugewiesenen Testdateien ab, die dann in eine durch Leerzeichen getrennte Liste umgewandelt werden. JUnit Führt im zweiten Lauf die Tests aus. Ruft erneut `CODEBUILD_CURRENT_SHARD_FILES` die Testdateien ab, die dem aktuellen Shard zugewiesen sind, aber diesmal werden sie in Klassennamen umgewandelt.
# Konfigurieren Sie parallel Tests mit PHPUnit
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung PHPUnit auf einer Linux-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 5
ignore-failure: false
phases:
install:
commands:
- echo 'Install dependencies'
- composer require --dev phpunit/phpunit
pre_build:
commands:
- echo 'prebuild'
build:
commands:
- echo 'Running phpunit Tests'
- composer dump-autoload
- |
codebuild-tests-run \
--test-command "./vendor/bin/phpunit --debug" \
--files-search "codebuild-glob-search '**/tests/*Test.php'"
post_build:
commands:
- echo 'Test execution completed'
```
# Konfigurieren Sie parallel Tests mit Pytest
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung mit Pytest auf einer Ubuntu-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 5
ignore-failure: false
phases:
install:
commands:
- echo 'Installing Python dependencies'
- apt-get update
- apt-get install -y python3 python3-pip
- pip3 install --upgrade pip
- pip3 install pytest
build:
commands:
- echo 'Running Python Tests'
- |
codebuild-tests-run \
--test-command 'python -m pytest' \
--files-search "codebuild-glob-search 'tests/test_*.py'" \
--sharding-strategy 'equal-distribution'
post_build:
commands:
- echo "Test execution completed"
```
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung mit Pytest auf einer Windows-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 5
ignore-failure: false
phases:
install:
commands:
- echo 'Installing Python dependencies'
- pip install pytest
pre_build:
commands:
- echo 'prebuild'
build:
commands:
- echo 'Running pytest'
- |
& codebuild-tests-run `
--test-command 'pytest @("$env:CODEBUILD_CURRENT_SHARD_FILES" -split \"`r?`n\")' `
--files-search "codebuild-glob-search '**/test_*.py' '**/*_test.py'" `
--sharding-strategy 'equal-distribution'
post_build:
commands:
- echo "Test execution completed"
```
Im obigen Beispiel wird die `CODEBUILD_CURRENT_SHARD_FILES` Umgebungsvariable verwendet, um Testdateien abzurufen, die dem aktuellen Shard zugewiesen sind und als Array an den Befehl pytest übergeben werden.
# Konfigurieren Sie parallel Tests mit Ruby (Cucumber)
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung mit Cucumber auf einer Linux-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 5
ignore-failure: false
phases:
install:
commands:
- echo 'Installing Ruby dependencies'
- gem install bundler
- bundle install
pre_build:
commands:
- echo 'prebuild'
build:
commands:
- echo 'Running Cucumber Tests'
- cucumber --init
- |
codebuild-tests-run \
--test-command "cucumber" \
--files-search "codebuild-glob-search '**/*.feature'"
post_build:
commands:
- echo "Test execution completed"
```
# parallel Tests mit Ruby (RSpec) konfigurieren
Das Folgende ist ein Beispiel für eine`buildspec.yml`, die die parallel Testausführung RSpec auf einer Ubuntu-Plattform zeigt:
```
version: 0.2
batch:
fast-fail: false
build-fanout:
parallelism: 5
ignore-failure: false
phases:
install:
commands:
- echo 'Installing Ruby dependencies'
- apt-get update
- apt-get install -y ruby ruby-dev build-essential
- gem install bundler
- bundle install
build:
commands:
- echo 'Running Ruby Tests'
- |
codebuild-tests-run \
--test-command 'bundle exec rspec' \
--files-search "codebuild-glob-search 'spec/**/*_spec.rb'" \
--sharding-strategy 'equal-distribution'
post_build:
commands:
- echo "Test execution completed"
```