Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Esegui test paralleli in build in batch
È possibile utilizzare AWS CodeBuild per eseguire test paralleli nelle build in batch. L'esecuzione parallela dei test è un approccio di test in cui più casi di test vengono eseguiti contemporaneamente su ambienti, macchine o browser diversi, anziché essere eseguiti in sequenza. Questo approccio può ridurre in modo significativo il tempo complessivo di esecuzione dei test e migliorare l'efficienza dei test. Inoltre CodeBuild, puoi suddividere i test in più ambienti ed eseguirli contemporaneamente.
I principali vantaggi dell'esecuzione parallela dei test includono:
1. **Tempo di esecuzione ridotto**: i test che richiederebbero ore in sequenza possono essere completati in pochi minuti.
1. **Migliore utilizzo delle risorse**: utilizza in modo efficiente le risorse di elaborazione disponibili.
1. **Feedback anticipato: un** completamento più rapido del test significa un feedback più rapido per gli sviluppatori.
1. **Conveniente**: consente di risparmiare tempo e costi di elaborazione a lungo termine.
Quando si implementa l'esecuzione di test paralleli, vengono comunemente considerati due approcci principali: ambienti separati e multithreading. Sebbene entrambi i metodi mirino a ottenere l'esecuzione simultanea dei test, differiscono in modo significativo nella loro implementazione ed efficacia. Ambienti separati creano istanze isolate in cui ogni suite di test viene eseguita in modo indipendente, mentre il multithreading esegue più test contemporaneamente all'interno dello stesso spazio di processo utilizzando thread diversi.
I vantaggi principali degli ambienti separati rispetto al multithreading includono:
1. **Isolamento**: ogni test viene eseguito in un ambiente completamente isolato, evitando interferenze tra i test.
1. **Conflitti di risorse**: nessuna concorrenza per le risorse condivise, cosa che spesso si verifica nel multithreading.
1. **Stabilità**: meno incline alle condizioni di gara e ai problemi di sincronizzazione.
1. **Debug più semplice**: quando i test falliscono, è più semplice identificare la causa poiché ogni ambiente è indipendente.
1. **Gestione dello stato: gestisci** facilmente i problemi di stato condivisi che affliggono i test multithread.
1. **Migliore scalabilità**: può aggiungere facilmente più ambienti senza complessità.
**Topics**
+ [Support in AWS CodeBuild](#parallel-test-support)
+ [Abilita l'esecuzione di test paralleli nelle build in batch](parallel-test-enable.md)
+ [Usa il comando `codebuild-tests-run` CLI](parallel-test-tests-run.md)
+ [Usa il comando `codebuild-glob-search` CLI](parallel-test-glob-search.md)
+ [Informazioni sulla suddivisione dei test](parallel-test-splitting.md)
+ [Unisci automaticamente i report di build individuali](parallel-test-auto-merge.md)
+ [Esempio di esecuzione parallela di test per vari framework di test](sample-parallel-test.md)
## Support in AWS CodeBuild
AWS CodeBuild fornisce un solido supporto per l'esecuzione di test paralleli tramite la sua funzionalità di creazione in batch, progettata specificamente per sfruttare l'esecuzione in ambienti separati. Questa implementazione si allinea perfettamente con i vantaggi degli ambienti di test isolati.
**Creazione in batch con distribuzione dei test**
CodeBuildla funzionalità di compilazione in batch consente la creazione di più ambienti di compilazione che vengono eseguiti contemporaneamente. Ogni ambiente funziona come un'unità completamente isolata, con risorse di elaborazione, ambiente di runtime e dipendenze propri. Tramite la configurazione di build in batch, puoi specificare quanti ambienti paralleli sono necessari e come i test devono essere distribuiti su di essi.
**CLI di partizionamento dei test**
CodeBuild include un meccanismo di distribuzione dei test integrato tramite il suo strumento CLI`codebuild-tests-run`, che divide automaticamente i test in diversi ambienti.
**Aggregazione dei report**
Uno dei principali punti di forza dell'implementazione è la sua capacità CodeBuild di gestire l'aggregazione dei risultati dei test senza problemi. Mentre i test vengono eseguiti in ambienti separati, raccoglie e combina CodeBuild automaticamente i report di test di ciascun ambiente in un rapporto di test unificato a livello di creazione del batch. Questo consolidamento fornisce una visione completa dei risultati dei test mantenendo i vantaggi in termini di efficienza dell'esecuzione parallela.
Di seguito è riportato il diagramma che spiega il concetto completo di esecuzione di test paralleli in AWS CodeBuild.
![\[Diagramma concettuale dell'esecuzione di test paralleli.\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/images/parallel-test.png)
# Abilita l'esecuzione di test paralleli nelle build in batch
Per eseguire i test in parallelo, aggiorna il file batch build buildspec per includere il campo build-fanout e il numero di build parallele per dividere la suite di test nel campo come mostrato di seguito. `parallelism` Il `parallelism` campo specifica quanti esecutori indipendenti sono configurati per eseguire la suite di test.
Per eseguire i test in più ambienti di esecuzione parallela, imposta il `parallelism` campo su un valore maggiore di zero. Nell'esempio seguente, `parallelism` è impostato su cinque, il che significa che CodeBuild avvia cinque build identiche che eseguono una parte della suite di test in parallelo.
Puoi usare il comando [codebuild-tests-run](parallel-test-tests-run.md)CLI per dividere ed eseguire i test. I file di test verranno suddivisi e una parte dei test verrà eseguita in ogni build. Ciò riduce il tempo complessivo impiegato per eseguire l'intera suite di test. Nell'esempio seguente, i test verranno suddivisi in cinque e i punti di divisione verranno calcolati in base al nome dei test.
```
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
```
Se i report sono configurati per la build build-fanout, i report di test vengono generati separatamente per ogni build, che possono essere visualizzati nella scheda **Report** delle build corrispondenti nella console. AWS CodeBuild
Per ulteriori informazioni su come eseguire test paralleli in batch, vedere[Esempio di esecuzione parallela di test per vari framework di test](sample-parallel-test.md).
# Usa il comando `codebuild-tests-run` CLI
AWS CodeBuild fornisce una CLI che prenderà come input il comando di test e la posizione del file di test. La CLI con questi input suddividerà i test in un numero di frammenti come specificato nel `parallelism` campo in base ai nomi dei file di test. L'assegnazione dei file di test agli shard viene decisa dalla strategia di sharding.
```
codebuild-tests-run \
--files-search "codebuild-glob-search '**/__tests__/*.js'" \
--test-command 'npx jest --runInBand --coverage' \
--sharding-strategy 'equal-distribution'
```
La tabella seguente descrive i campi per il comando `codebuild-tests-run` CLI.
| Nome del campo | Tipo | Obbligatorio o facoltativo | Definizione |
| --- | --- | --- | --- |
| `test-command` | Stringa | Richiesto | Questo comando viene utilizzato per eseguire i test. |
| `files-search` | Stringa | Richiesto | Questo comando fornisce un elenco di file di test. Puoi utilizzare il comando [codebuild-glob-search](parallel-test-glob-search.md)CLI AWS CodeBuild fornito o qualsiasi altro strumento di ricerca di file a tua scelta. Assicurati che il `files-search` comando restituisca i nomi dei file, ciascuno separato da una nuova riga. |
| `sharding-strategy` | Enum | Facoltativo | Valori validi: `equal-distribution` (valore predefinito), `stability` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codebuild/latest/userguide/parallel-test-tests-run.html) Per ulteriori informazioni, consulta [Informazioni sulla suddivisione dei test](parallel-test-splitting.md). |
La `codebuild-tests-run` CLI funziona innanzitutto per identificare l'elenco dei file di test utilizzando il comando fornito nel `files-search` parametro. Quindi determina un sottoinsieme di file di test designati per lo shard (ambiente) corrente utilizzando la strategia di sharding specificata. Infine, questo sottoinsieme di file di test viene formattato in un elenco separato da spazi e aggiunto alla fine del comando fornito nel parametro prima di essere eseguito. `test-command`
Per i framework di test che non accettano elenchi separati da spazi, la `codebuild-tests-run` CLI fornisce un'alternativa flessibile tramite la variabile di ambiente. `CODEBUILD_CURRENT_SHARD_FILES` Questa variabile contiene un elenco separato da nuova riga di percorsi di file di test designati per lo shard di build corrente. Sfruttando questa variabile di ambiente, puoi adattarti facilmente a vari requisiti del framework di test, soddisfacendo quelli che prevedono formati di input diversi dagli elenchi separati da spazi. Inoltre, puoi anche formattare i nomi dei file di test in base alle esigenze del framework di test. Di seguito è riportato un esempio dell'utilizzo di `CODEBUILD_CURRENT_SHARD_FILES` su Linux con il framework Django. Qui `CODEBUILD_CURRENT_SHARD_FILES` viene utilizzato per ottenere i percorsi dei file *con notazione a punti* supportati da Django:
```
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'
```
**Nota**
Nota che la variabile di `CODEBUILD_CURRENT_SHARD_FILES` ambiente può essere utilizzata solo all'interno dell'ambito della `codebuild-tests-run` CLI.
Inoltre, se stai usando `CODEBUILD_CURRENT_SHARD_FILES` inside test-command, inserisci `CODEBUILD_CURRENT_SHARD_FILES` tra virgolette doppie come mostrato nell'esempio precedente.
# Usa il comando `codebuild-glob-search` CLI
AWS CodeBuild fornisce uno strumento CLI integrato chiamato `codebuild-glob-search` che consente di cercare file nella directory di lavoro in base a uno o più modelli di glob. Questo strumento può essere particolarmente utile quando si desidera eseguire test su file o directory specifici all'interno del progetto.
## Utilizzo
La `codebuild-glob-search` CLI ha la seguente sintassi di utilizzo:
```
codebuild-glob-search [ ...]
```
+ ````, ecc.: Uno o più pattern globulari da confrontare con i file nella directory di lavoro.
+ `*`: Corrisponde a qualsiasi sequenza di caratteri (esclusi i separatori di percorso).
+ `**`: corrisponde a qualsiasi sequenza di caratteri (inclusi i separatori di percorso).
**Nota**
Assicurati che la stringa glob contenga virgolette. Per verificare i risultati del pattern-matching, usa il comando. `echo`
```
version: 0.2
phases:
build:
commands:
- echo $(codebuild-glob-search '**/__tests__/*.js')
- codebuild-glob-search '**/__tests__/*.js' | xargs -n 1 echo
```
## Output
La CLI produrrà un elenco separato da nuove righe di percorsi di file che corrispondono ai modelli di glob forniti. I percorsi dei file restituiti saranno relativi alla directory di lavoro.
Se non viene trovato alcun file corrispondente ai modelli forniti, la CLI emetterà un messaggio che indica che non è stato trovato alcun file.
Tieni presente che le directory trovate a causa di un determinato modello verranno escluse dai risultati della ricerca.
## Esempio
Se vuoi cercare solo i file all'interno della directory tests e delle sue sottodirectory con `.js` estensione, puoi usare il seguente comando con la `codebuild-glob-search` CLI:
```
codebuild-glob-search '**/__tests__/*.js'
```
Questo comando cercherà tutti i file con `.js` estensione all'interno della `__tests__` directory e delle relative sottodirectory, come indicato dal modello.
# Informazioni sulla suddivisione dei test
AWS CodeBuild consente di parallelizzare l'esecuzione della suite di test su più istanze di calcolo, riducendo il tempo complessivo di esecuzione del test. Questa funzionalità è abilitata tramite la configurazione batch nelle impostazioni del CodeBuild progetto e l'`codebuild-tests-run`utilità nel file buildspec.
I test vengono suddivisi in base alla strategia di sharding specificata. CodeBuild fornisce due strategie di sharding come specificato di seguito:
Distribuzione equa
La strategia `equal-distribution` di sharding divide i test in build parallele in base all'ordine alfabetico dei nomi dei file di test. Questo approccio ordina innanzitutto i file di test e poi utilizza un metodo basato su blocchi per distribuirli, assicurando che file simili vengano raggruppati insieme per i test. È consigliato quando si ha a che fare con un insieme relativamente piccolo di file di test. Sebbene questo metodo miri ad allocare un numero approssimativamente uguale di file a ogni shard, con una differenza massima di uno, non garantisce la stabilità. Quando i file di test vengono aggiunti o rimossi nelle build successive, la distribuzione dei file esistenti può cambiare, causando potenzialmente la riassegnazione tra gli shard.
Stabilità
La strategia di `stability` sharding utilizza un algoritmo di hashing coerente per suddividere i test tra gli shard, garantendo che la distribuzione dei file rimanga stabile. Quando vengono aggiunti o rimossi nuovi file, questo approccio garantisce che le file-to-shard assegnazioni esistenti rimangano sostanzialmente invariate. Per suite di test di grandi dimensioni, si consiglia di utilizzare l'opzione di stabilità per distribuire uniformemente i test tra gli shard. Questo meccanismo mira a fornire una distribuzione quasi uguale, garantendo che ogni shard riceva un numero simile di file, con una varianza minima. Sebbene la strategia di stabilità non garantisca una distribuzione equa ideale, offre una distribuzione quasi uguale che mantiene la coerenza nelle assegnazioni dei file tra le build, anche quando i file vengono aggiunti o rimossi.
Per abilitare la suddivisione dei test, è necessario configurare la sezione batch nelle impostazioni del CodeBuild progetto, specificando il livello desiderato `parallelism` e altri parametri pertinenti. Inoltre, è necessario includere l'`codebuild-tests-run`utilità nel file buildspec, insieme ai comandi di test e al metodo di suddivisione appropriati.
# Unisci automaticamente i report di build individuali
Nelle build in batch fanout, AWS CodeBuild supporta l'unione automatica dei singoli report di build in un report consolidato a livello di batch. Questa funzionalità offre una visione completa dei risultati dei test e della copertura del codice in tutte le build all'interno di un batch.
## Come funziona
Quando si eseguono build `fanout` in batch, ogni singola build genera report di [test](test-reporting.md). CodeBuild quindi consolida automaticamente report identici provenienti da build diverse in un report unificato, che viene allegato alla build batch. Questi report consolidati sono facilmente accessibili tramite il `reportArns` campo dell'[ BatchGetBuildBatches](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_BatchGetBuildBatches.html#CodeBuild-BatchGetBuildBatches-response-buildBatches)API e possono essere visualizzati anche nella scheda **Report** della console. Questa funzionalità di fusione si estende anche ai report rilevati automaticamente.
I report consolidati vengono creati in [gruppi di report](test-report-group.md) specificati nelle specifiche della build o scoperti automaticamente da. CodeBuild Puoi analizzare le tendenze dei report uniti direttamente in questi gruppi di report, fornendo informazioni preziose sulle metriche complessive, sulle prestazioni di costruzione e sulle metriche di qualità nelle build storiche dello stesso progetto in batch di compilazione.
Per ogni singola build all'interno del batch, crea CodeBuild automaticamente gruppi di report separati. Questi seguono una convenzione di denominazione specifica, che combina il nome del gruppo di report creato in batch con un suffisso di`BuildFanoutShard`, dove `shard_number` rappresenta il numero dello shard in cui viene creato il gruppo di report. Questa organizzazione consente di tracciare e analizzare le tendenze sia a livello di compilazione consolidato che individuale, offrendo flessibilità nel modo in cui monitorate e valutate i relativi processi di compilazione.
Il rapporto di creazione in batch segue la stessa struttura dei report di compilazione [individuali](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Report.html). I seguenti campi chiave nella scheda **Report sono specifici per i report** creati in batch:
**Stato del report relativo alla creazione in Batch**
Lo stato dei report di creazione in batch segue regole specifiche a seconda del tipo di report:
+ Rapporti di test:
+ Riuscito: lo stato viene impostato su Riuscito quando tutti i singoli report di compilazione hanno avuto esito positivo.
+ Non riuscito: lo stato è impostato su Non riuscito se un singolo report di compilazione non è riuscito.
+ Incompleto: lo stato viene contrassegnato come incompleto se un singolo rapporto di compilazione è mancante o presenta uno stato incompleto.
+ Rapporti sulla copertura del codice:
+ Completo: lo stato viene impostato per essere completato quando tutti i report di compilazione individuali sono completi.
+ Non riuscito: lo stato è impostato su Non riuscito se un singolo report di compilazione non è riuscito.
+ Incompleto: lo stato viene contrassegnato come incompleto se un singolo rapporto di compilazione è mancante o presenta uno stato incompleto.
**Riepilogo del test**
Il rapporto di test unito consolida i seguenti campi di tutti i singoli report di build:
+ duration-in-nano-seconds: Durata massima del test in nanosecondi tra tutti i singoli report di build.
+ totale: il conteggio combinato di tutti i casi di test, sommando il numero totale di test di ciascuna build.
+ conteggi degli stati: fornisce una visualizzazione consolidata degli stati dei test, ad esempio superati, non riusciti o ignorati, calcolati aggregando il conteggio di ogni tipo di stato in tutte le singole build.
**Riepilogo della copertura del codice**
Il rapporto sulla copertura del codice unito combina i campi di tutte le singole build utilizzando i seguenti calcoli:
+ filiali coperte: somma di tutte le filiali coperte dai singoli report.
+ succursali perse: somma di tutte le filiali mancanti riportate nelle segnalazioni individuali.
+ branch-coverage-percentage: `(Total covered branches / Total branches) * 100`
+ righe coperte: somma di tutte le righe coperte dai singoli report.
+ righe mancanti: somma di tutte le righe mancanti dei singoli report.
+ lines-coverage-percentage: `(Total covered lines / Total lines) * 100`
**ID di esecuzione**
L'ARN di compilazione in batch.
**Casi di test**
Il report unito contiene un elenco consolidato di tutti i casi di test relativi alle singole build, accessibile sia tramite l'[DescribeTestCases](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_DescribeTestCases.html)API che tramite il rapporto sulla build in batch nella console.
**Coperture del codice**
Il rapporto sulla copertura del codice unito fornisce informazioni consolidate sulla copertura di linee e filiali per ogni file in tutte le singole build, accessibili sia tramite l'[DescribeCodeCoverages](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_DescribeCodeCoverages.html)API che tramite il rapporto di creazione in batch nella console. Nota: per i file coperti da più file di test distribuiti su diversi shard, il report unito utilizza i seguenti criteri di selezione:
1. La selezione primaria si basa sulla copertura di linea più alta tra gli shard.
1. Se la copertura di linea è uguale su più frammenti, viene selezionato lo shard con la copertura di diramazione più elevata.
# Esempio di esecuzione parallela di test per vari framework di test
Puoi usare il comando `codebuild-tests-run` CLI per dividere ed eseguire i test in ambienti di esecuzione parallela. La sezione seguente fornisce `buildspec.yml` esempi per vari framework, illustrando l'utilizzo del comando. `codebuild-tests-run`
+ Ogni esempio seguente include un `parallelism` livello di cinque, il che significa che verranno creati cinque ambienti di esecuzione identici per suddividere i test. Puoi scegliere un `parallelism` livello adatto al tuo progetto modificando il `parallelism` valore nella `build-fanout` sezione.
+ Ogni esempio seguente mostra la configurazione dei test in modo che vengano divisi in base al nome del file di test, che è quello predefinito. Questo distribuisce i test in modo uniforme negli ambienti di esecuzione parallela.
Prima di iniziare, consulta [Esegui test paralleli in build in batch](parallel-test.md) per ulteriori informazioni.
Per un elenco completo delle opzioni quando si utilizza il comando `codebuild-tests-run` CLI, vedere. [Usa il comando `codebuild-tests-run` CLI](parallel-test-tests-run.md)
**Topics**
+ [Configura test paralleli con Django](sample-parallel-test-django.md)
+ [Configura test paralleli con Elixir](sample-parallel-test-elixir.md)
+ [Configura test paralleli con Go](sample-parallel-test-go.md)
+ [Configurare test paralleli con Java (Maven)](sample-parallel-test-java-maven.md)
+ [Configura test paralleli con Javascript (Jest)](sample-parallel-test-javascript.md)
+ [Configura test paralleli con Kotlin](sample-parallel-test-kotlin.md)
+ [Configura test paralleli con PHPUnit](sample-parallel-test-phpunit.md)
+ [Configura test paralleli con Pytest](sample-parallel-test-python.md)
+ [Configura test paralleli con Ruby (Cucumber)](sample-parallel-test-ruby-cucumber.md)
+ [Configura test paralleli con Ruby () RSpec](sample-parallel-test-ruby.md)
# Configura test paralleli con Django
Di seguito è riportato un esempio `buildspec.yml` che mostra l'esecuzione di test paralleli con Django su una piattaforma Ubuntu:
```
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'
```
L'esempio precedente mostra l'utilizzo della variabile `CODEBUILD_CURRENT_SHARD_FILES` di ambiente. Qui `CODEBUILD_CURRENT_SHARD_FILES` viene utilizzato per recuperare i percorsi dei file di notazione a punti supportati da Django. Usa le virgolette doppie `CODEBUILD_CURRENT_SHARD_FILES` all'interno come mostrato sopra.
# Configura test paralleli con Elixir
Di seguito è riportato un esempio `buildspec.yml` che mostra l'esecuzione di test paralleli con Elixir su una piattaforma Ubuntu:
```
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"
```
# Configura test paralleli con Go
Di seguito è riportato un esempio `buildspec.yml` che mostra l'esecuzione di test paralleli con Go su una piattaforma Linux:
```
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"
```
Nell'esempio precedente, `calculator.go` la funzione contiene semplici funzioni matematiche da testare e tutti i file e i file di test si trovano all'interno della `calc` cartella. `calculator.go`
# Configurare test paralleli con Java (Maven)
Di seguito è riportato un esempio `buildspec.yml` che mostra l'esecuzione di test paralleli con Java su una piattaforma Linux:
```
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"
```
Nell'esempio riportato, la variabile di ambiente `CODEBUILD_CURRENT_SHARD_FILES` contiene file di test nello shard corrente, separati da nuove righe. Questi file vengono convertiti in un elenco di nomi di classi separati da virgole nel formato accettato dal parametro per Maven. `-Dtest`
# Configura test paralleli con Javascript (Jest)
Di seguito è riportato un esempio `buildspec.yml` che mostra l'esecuzione di test paralleli con Javascript su una piattaforma Ubuntu:
```
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'
```
# Configura test paralleli con Kotlin
Di seguito è riportato un esempio `buildspec.yml` che mostra l'esecuzione di test paralleli con Kotlin su una piattaforma Linux:
```
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"
```
Nell'esempio precedente, la `codebuild-tests-run` CLI viene utilizzata due volte. Durante la prima esecuzione, kotlinc compila i file. La `CODEBUILD_CURRENT_SHARD_FILES` variabile recupera i file di test assegnati allo shard corrente, che vengono poi convertiti in un elenco separato da spazi. Nella seconda esecuzione, JUnit esegue i test. Ancora una volta, `CODEBUILD_CURRENT_SHARD_FILES` recupera i file di test assegnati allo shard corrente, ma questa volta vengono convertiti in nomi di classe.
# Configura test paralleli con PHPUnit
Di seguito è riportato un esempio di un test `buildspec.yml` che mostra l'esecuzione di test paralleli PHPUnit su una piattaforma Linux:
```
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'
```
# Configura test paralleli con Pytest
Di seguito è riportato un esempio `buildspec.yml` che mostra l'esecuzione di test paralleli con Pytest su una piattaforma Ubuntu:
```
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"
```
Di seguito è riportato un esempio `buildspec.yml` che mostra l'esecuzione di test paralleli con Pytest su una piattaforma Windows:
```
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"
```
Nell'esempio precedente, la variabile di `CODEBUILD_CURRENT_SHARD_FILES` ambiente viene utilizzata per recuperare i file di test assegnati allo shard corrente e passati come array al comando pytest.
# Configura test paralleli con Ruby (Cucumber)
Di seguito è riportato un esempio `buildspec.yml` che mostra l'esecuzione di test paralleli con Cucumber su una piattaforma Linux:
```
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"
```
# Configura test paralleli con Ruby () RSpec
Di seguito è riportato un esempio di un test `buildspec.yml` che mostra l'esecuzione di test paralleli RSpec su una piattaforma Ubuntu:
```
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"
```