As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Executar testes paralelos em compilações em lote
Você pode usar AWS CodeBuild para executar testes paralelos em compilações em lote. A execução de testes em paralelo é uma abordagem em que vários casos de teste são executados simultaneamente em diferentes ambientes, máquinas ou navegadores, em vez de serem executados sequencialmente. Essa abordagem pode reduzir significativamente o tempo geral de execução e melhorar a eficiência de testes. Em CodeBuild, você pode dividir seus testes em vários ambientes e executá-los simultaneamente.
As principais vantagens da execução de testes em paralelo incluem:
1. **Tempo de execução reduzido**: testes que levariam horas sequencialmente podem ser concluídos em minutos.
1. **Melhor utilização dos recursos**: faz uso eficiente dos recursos de computação disponíveis.
1. **Feedback antecipado**: a conclusão mais rápida do teste significa um feedback mais rápido para os desenvolvedores.
1. **Econômico**: economiza tempo e custos de computação a longo prazo.
Ao implementar a execução de testes em paralelo, duas abordagens principais costumam ser consideradas: ambientes separados e multithreading. Embora ambos os métodos tenham como objetivo alcançar a execução simultânea de testes, eles diferem significativamente em sua implementação e eficácia. Ambientes separados criam instâncias isoladas em que cada suíte de testes é executada de forma independente, enquanto o multithreading executa vários testes simultaneamente no mesmo espaço de processo usando diferentes threads.
As principais vantagens de ambientes separados em relação ao multithreading incluem:
1. **Isolamento**: cada teste é executado em um ambiente totalmente isolado, evitando interferência entre os testes.
1. **Conflitos de recursos**: não há competição por recursos compartilhados, o que geralmente ocorre em multithreading.
1. **Estabilidade**: menos propenso a condições de corrida e problemas de sincronização.
1. **Depuração mais fácil**: quando os testes falham, é mais simples identificar a causa, pois cada ambiente é independente.
1. **Gerenciamento de estado**: gerencie facilmente os problemas de estado compartilhado que afetam os testes multithread.
1. **Melhor escalabilidade**: pode adicionar facilmente mais ambientes sem complexidade.
**Topics**
+ [Support em AWS CodeBuild](#parallel-test-support)
+ [Habilitar a execução de testes em paralelo em compilações em lote](parallel-test-enable.md)
+ [Usar o comando `codebuild-tests-run` da CLI](parallel-test-tests-run.md)
+ [Usar o comando `codebuild-glob-search` da CLI](parallel-test-glob-search.md)
+ [Sobre a divisão de testes](parallel-test-splitting.md)
+ [Mesclar automaticamente relatórios de compilação individuais](parallel-test-auto-merge.md)
+ [Exemplo de execução de testes em paralelo para vários frameworks de teste](sample-parallel-test.md)
## Support em AWS CodeBuild
AWS CodeBuild fornece suporte robusto para execução paralela de testes por meio de seu recurso de criação em lote, projetado especificamente para aproveitar a execução de ambientes separados. Essa implementação se alinha perfeitamente aos benefícios de ambientes de teste isolados.
**Compilação em lote com distribuição de testes**
CodeBuildA funcionalidade de criação em lote do permite a criação de vários ambientes de construção que são executados simultaneamente. Cada ambiente opera como uma unidade totalmente isolada, com seus próprios recursos computacionais, ambiente de runtime e dependências. Por meio da configuração de compilação em lote, é possível especificar quantos ambientes paralelos são necessários e como os testes devem ser distribuídos entre eles.
**Testar a CLI de fragmentação**
CodeBuild inclui um mecanismo de distribuição de testes integrado por meio de sua ferramenta CLI`codebuild-tests-run`, que divide automaticamente os testes em diferentes ambientes.
**Agregação de relatórios**
Um dos principais pontos fortes da implementação é a capacidade CodeBuild de lidar com a agregação de resultados de testes sem problemas. Enquanto os testes são executados em ambientes separados, coleta e combina CodeBuild automaticamente os relatórios de teste de cada ambiente em um relatório de teste unificado no nível de criação em lote. Essa consolidação fornece uma visão abrangente dos resultados dos testes, mantendo os benefícios de eficiência da execução paralela.
O diagrama a seguir explica o conceito completo de execução de testes em paralelo no AWS CodeBuild.
![\[Diagrama conceitual da execução de testes em paralelo.\]](http://docs.aws.amazon.com/pt_br/codebuild/latest/userguide/images/parallel-test.png)
# Habilitar a execução de testes em paralelo em compilações em lote
Para executar testes em paralelo, atualize o arquivo buildspec de compilação em lote para incluir o campo build-fanout de compilação e o número de compilações paralelas para dividir o conjunto de testes no campo `parallelism`, conforme mostrado abaixo. O campo `parallelism` especifica quantos executores independentes estão configurados para executar a suíte de testes.
Para executar os testes em vários ambientes de execução paralela, defina o campo `parallelism` com um valor acima de zero. No exemplo abaixo, `parallelism` está definido como cinco, o que significa que CodeBuild inicia cinco compilações idênticas que executam uma parte da suíte de testes em paralelo.
Você pode usar o comando [codebuild-tests-run](parallel-test-tests-run.md)CLI para dividir e executar seus testes. Os arquivos de teste serão divididos e uma parte dos testes será executada em cada compilação. Isso reduz o tempo total necessário para executar a suíte de testes completa. No exemplo a seguir, os testes serão divididos em cinco e os pontos de divisão serão calculados com base no nome dos testes.
```
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 os relatórios forem configurados para compilação build-fanout, os relatórios de teste serão gerados para cada compilação separadamente, que podem ser visualizados na guia **Relatórios** das compilações correspondentes no console. AWS CodeBuild
Consulte mais informações sobre como executar testes em paralelo em lote em [Exemplo de execução de testes em paralelo para vários frameworks de teste](sample-parallel-test.md).
# Usar o comando `codebuild-tests-run` da CLI
AWS CodeBuild fornece uma CLI que tomará o comando de teste e a localização do arquivo de teste como entrada. A CLI com essas entradas divide os testes em número de fragmentos, conforme especificado no campo `parallelism`, com base nos nomes dos arquivos de teste. A atribuição dos arquivos de teste ao fragmento é decidida pela estratégia de fragmentação.
```
codebuild-tests-run \
--files-search "codebuild-glob-search '**/__tests__/*.js'" \
--test-command 'npx jest --runInBand --coverage' \
--sharding-strategy 'equal-distribution'
```
A tabela a seguir descreve os campos para o comando `codebuild-tests-run` da CLI.
| Nome do campo | Tipo | Obrigatório ou opcional | Definição |
| --- | --- | --- | --- |
| `test-command` | String | Obrigatório | Esse comando é usado para executar os testes. |
| `files-search` | String | Obrigatório | Esse comando fornece uma lista de arquivos de teste. Você pode usar o comando [codebuild-glob-search](parallel-test-glob-search.md)CLI AWS CodeBuild fornecido ou qualquer outra ferramenta de pesquisa de arquivos de sua escolha. Certifique-se de que o comando `files-search` produza os nomes dos arquivos, cada um separado por uma nova linha. |
| `sharding-strategy` | Enum | Opcional | Valores válidos: `equal-distribution` (padrão), `stability` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codebuild/latest/userguide/parallel-test-tests-run.html) Para obter mais informações, consulte [Sobre a divisão de testes](parallel-test-splitting.md). |
A CLI `codebuild-tests-run` funciona primeiro para identificar a lista de arquivos de teste usando o comando fornecido no parâmetro `files-search`. Depois, ela determina um subconjunto de arquivos de teste designados para o fragmento (ambiente) atual usando a estratégia de fragmentação especificada. Por fim, esse subconjunto de arquivos de teste é formatado como uma lista separada por espaços e anexado ao final do comando fornecido no parâmetro `test-command` antes de ser executado.
Para frameworks de teste que não aceitam listas separadas por espaço, a CLI `codebuild-tests-run` fornece uma alternativa flexível por meio da variável de ambiente `CODEBUILD_CURRENT_SHARD_FILES`. Essa variável contém uma lista de caminhos de arquivos de teste, separados por quebras de linha, designados para o fragmento de compilação atual. Ao aproveitar essa variável de ambiente, você pode se adaptar facilmente a vários requisitos do framework de teste, acomodando aqueles que esperam formatos de entrada diferentes das listas separadas por espaço. Além disso, você também pode formatar os nomes dos arquivos de teste conforme a necessidade do framework de teste. Veja a seguir um exemplo do uso de `CODEBUILD_CURRENT_SHARD_FILES` no Linux com o framework do Django. Aqui, `CODEBUILD_CURRENT_SHARD_FILES` é usado para obter caminhos de arquivos em *notação com pontos* compatíveis com o 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**
Observe que a variável de ambiente `CODEBUILD_CURRENT_SHARD_FILES` só pode ser usada dentro do escopo da CLI `codebuild-tests-run`.
Além disso, se você estiver usando `CODEBUILD_CURRENT_SHARD_FILES` dentro do comando de teste, coloque `CODEBUILD_CURRENT_SHARD_FILES` entre aspas duplas, conforme mostrado no exemplo acima.
# Usar o comando `codebuild-glob-search` da CLI
AWS CodeBuild fornece uma ferramenta CLI integrada chamada `codebuild-glob-search` que permite pesquisar arquivos em seu diretório de trabalho com base em um ou mais padrões globais. Essa ferramenta pode ser útil principalmente quando você deseja executar testes em arquivos ou diretórios específicos do projeto.
## Uso
A CLI `codebuild-glob-search` tem a seguinte sintaxe de uso:
```
codebuild-glob-search [ ...]
```
+ ``, `` etc.: um ou mais padrões globais para comparar com os arquivos em seu diretório de trabalho.
+ `*`: corresponde a qualquer sequência de caracteres (exceto separadores de caminho).
+ `**`: corresponde a qualquer sequência de caracteres (incluindo separadores de caminho).
**nota**
A string global deve ter aspas. Para verificar os resultados da correspondência de padrões, use o comando `echo`.
```
version: 0.2
phases:
build:
commands:
- echo $(codebuild-glob-search '**/__tests__/*.js')
- codebuild-glob-search '**/__tests__/*.js' | xargs -n 1 echo
```
## Output
A CLI gera uma lista de caminhos de arquivos, separados por quebras de linha, que correspondem aos padrões de glob fornecidos. Os caminhos de arquivo retornados serão relativos ao diretório de trabalho.
Se nenhum arquivo que corresponda aos padrões fornecidos for encontrado, a CLI exibirá uma mensagem indicando que nenhum arquivo foi encontrado.
Observe que os diretórios encontrados devido a qualquer padrão serão excluídos dos resultados da pesquisa.
## Exemplo
Se quiser pesquisar somente arquivos dentro do diretório de testes e seus subdiretórios com uma extensão `.js`, você poderá usar o seguinte comando com a CLI `codebuild-glob-search`:
```
codebuild-glob-search '**/__tests__/*.js'
```
Esse comando pesquisará todos os arquivos com uma extensão `.js` dentro do diretório `__tests__` e seus subdiretórios, conforme indicado pelo padrão.
# Sobre a divisão de testes
O recurso de divisão de testes do AWS CodeBuild permite paralelizar a execução da suíte de testes em várias instâncias de computação, reduzindo o tempo geral de execução do teste. Esse recurso é ativado por meio da configuração em lote nas configurações CodeBuild do projeto e do `codebuild-tests-run` utilitário no arquivo buildspec.
Os testes são divididos com base na estratégia de fragmentação especificada. CodeBuild fornece duas estratégias de fragmentação, conforme especificado abaixo:
Distribuição igualitária
A estratégia de fragmentação `equal-distribution` divide os testes em compilações paralelas com base na ordem alfabética dos nomes dos arquivos de teste. Essa abordagem primeiro classifica os arquivos de teste e, depois, emprega um método baseado em fragmentos para distribuí-los, garantindo que arquivos semelhantes sejam agrupados para teste. Ela é recomendado ao lidar com um conjunto relativamente pequeno de arquivos de teste. Embora esse método tenha como objetivo alocar um número aproximadamente igual de arquivos para cada fragmento, com uma diferença máxima de um, ele não garante estabilidade. Quando arquivos de teste são adicionados ou removidos em compilações subsequentes, a distribuição dos arquivos existentes pode mudar, podendo causar a reatribuição entre fragmentos.
Estabilidade
A estratégia de fragmentação `stability` emprega um algoritmo de hash consistente para dividir os testes entre fragmentos, garantindo que a distribuição de arquivos permaneça estável. Quando novos arquivos são adicionados ou removidos, essa abordagem garante que as file-to-shard atribuições existentes permaneçam praticamente inalteradas. Para suítes de teste grandes, é recomendável usar a opção de estabilidade para distribuir uniformemente os testes entre os fragmentos. O objetivo desse mecanismo é fornecer uma distribuição quase igual, garantindo que cada fragmento receba um número similar de arquivos, com apenas uma variação mínima. Embora a estratégia de estabilidade não garanta uma distribuição igualitária ideal, ela oferece uma distribuição quase igual que mantém a consistência nas atribuições de arquivos entre compilações, mesmo quando os arquivos são adicionados ou removidos.
Para habilitar a divisão de testes, você precisa configurar a seção de lotes nas configurações do seu CodeBuild projeto, especificando o `parallelism` nível desejado e outros parâmetros relevantes. Além disso, você precisará incluir o utilitário `codebuild-tests-run` no arquivo buildspec, junto com os comandos de teste e o método de divisão apropriados.
# Mesclar automaticamente relatórios de compilação individuais
Nas compilações de lote do Fanout, AWS CodeBuild suporta a mesclagem automática de relatórios de compilação individuais em um relatório consolidado em nível de lote. Esse recurso fornece uma visão abrangente dos resultados dos testes e da cobertura do código em todas as compilações em um lote.
## Como funciona
Ao executar compilações `fanout` em lote, cada compilação individual gera relatórios de [teste](test-reporting.md). CodeBuild em seguida, consolida automaticamente relatórios idênticos de diferentes compilações em um relatório unificado, que é anexado à criação em lote. Esses relatórios consolidados são facilmente acessíveis por meio do `reportArns` campo da [ BatchGetBuildBatches](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_BatchGetBuildBatches.html#CodeBuild-BatchGetBuildBatches-response-buildBatches)API e também podem ser visualizados na guia **Relatórios** do console. Esse recurso de mesclagem também se estende aos relatórios descobertos automaticamente.
Os relatórios consolidados são criados em [grupos de relatórios](test-report-group.md) que são especificados no buildspec ou descobertos automaticamente por. CodeBuild É possível analisar as tendências dos relatórios mesclados diretamente nesses grupos de relatórios, fornecendo informações valiosas sobre o desempenho geral da compilação e as métricas de qualidade em compilações históricas do mesmo projeto de compilação em lote.
Para cada compilação individual dentro do lote, cria CodeBuild automaticamente grupos de relatórios separados. Eles seguem uma convenção de nomenclatura específica, combinando o nome do grupo de relatórios de criação em lote com um sufixo de `BuildFanoutShard`, onde `shard_number` representa o número do fragmento no qual o grupo de relatórios é criado. Essa organização permite que você acompanhe e analise tendências nos níveis de compilação consolidado e individual, oferecendo flexibilidade na forma de monitorar e avaliar seus processos de compilação.
O relatório de compilação em lote segue a mesma estrutura dos [relatórios de compilação individual](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Report.html). Os seguintes campos-chave na guia **Relatório** são específicos dos relatórios de compilação em lote:
**Status do relatório de compilação em lote**
O status dos relatórios de compilação em lote segue regras específicas, dependendo do tipo de relatório:
+ Relatórios de teste:
+ Bem-sucedido: o status será definido como “bem-sucedido” quando todos os relatórios de compilação individual tiverem sido bem-sucedidos.
+ Falha: o status será definido como “falha” se algum relatório de compilação individual falhar.
+ Incompleto: o status será marcado como “incompleto” se algum relatório de compilação individual estiver ausente ou tiver um status de “incompleto”.
+ Relatórios de cobertura de código:
+ Concluído: o status será definido como “concluído” quando todos os relatórios de compilação individual forem concluídos.
+ Falha: o status será definido como “falha” se algum relatório de compilação individual falhar.
+ Incompleto: o status será marcado como “incompleto” se algum relatório de compilação individual estiver ausente ou tiver um status de “incompleto”.
**Resumo de teste**
O relatório de teste mesclado consolida os seguintes campos de todos os relatórios de compilação individual:
+ duration-in-nano-seconds: Tempo máximo de duração do teste em nanossegundos entre todos os relatórios de criação individuais.
+ total: a contagem combinada de todos os casos de teste, somando o número total de testes de cada compilação.
+ status-counts: fornece uma visão consolidada dos status do teste, como “aprovado”, “reprovado” ou “ignorado”, o que é calculado agregando a contagem de cada tipo de status em todas as compilações individuais.
**Resumo da cobertura de código**
O relatório de cobertura de código mesclado combina campos de todas as compilações individuais usando os seguintes cálculos:
+ branches-covered: soma de todas as ramificações cobertas de relatórios individuais.
+ branches-missed: soma de todas as ramificações cobertas de relatórios individuais.
+ branch-coverage-percentage: `(Total covered branches / Total branches) * 100`
+ lines-covered: soma de todas as linhas cobertas de relatórios individuais.
+ lines-missed: soma de todas as linhas perdidas de relatórios individuais.
+ lines-coverage-percentage: `(Total covered lines / Total lines) * 100`
**ID de execução**
O ARN de compilação em lote.
**Casos de teste**
O relatório mesclado contém uma lista consolidada de todos os casos de teste de compilações individuais, acessível por meio da [DescribeTestCases](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_DescribeTestCases.html)API e do relatório de criação em lote no console.
**Coberturas de código**
O relatório de cobertura de código mesclado fornece informações consolidadas de cobertura de linha e ramificação para cada arquivo em todas as compilações individuais, acessíveis por meio da [DescribeCodeCoverages](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_DescribeCodeCoverages.html)API e do relatório de criação em lote no console. Nota: para arquivos cobertos por vários arquivos de teste distribuídos em diferentes fragmentos, o relatório mesclado usa os seguintes critérios de seleção:
1. A seleção primária é baseada na maior cobertura de linha entre os fragmentos.
1. Se a cobertura da linha for igual em vários fragmentos, aquele com a maior cobertura de ramificação será selecionado.
# Exemplo de execução de testes em paralelo para vários frameworks de teste
É possível usar o comando `codebuild-tests-run` da CLI para dividir e executar testes em ambientes de execução paralela. A seção a seguir fornece exemplos de `buildspec.yml` de vários frameworks, ilustrando o uso do comando `codebuild-tests-run`.
+ Cada exemplo abaixo inclui um nível de `parallelism` de cinco, o que significa que cinco ambientes de execução idênticos serão criados para dividir os testes. É possível escolher um nível de `parallelism` adequado ao projeto modificando o valor de `parallelism` na seção `build-fanout`.
+ Cada exemplo abaixo mostra como configurar os testes para serem divididos pelo nome do arquivo de teste, que é o padrão. Isso distribui os testes uniformemente nos ambientes de execução paralela.
Antes de começar, consulte mais informações em [Executar testes paralelos em compilações em lote](parallel-test.md).
Consulte uma lista completa das opções ao usar o comando `codebuild-tests-run` da CLI em [Usar o comando `codebuild-tests-run` da CLI](parallel-test-tests-run.md).
**Topics**
+ [Configurar testes em paralelo com o Django](sample-parallel-test-django.md)
+ [Configurar testes em paralelo com o Elixir](sample-parallel-test-elixir.md)
+ [Configurar testes em paralelo com o Go](sample-parallel-test-go.md)
+ [Configurar testes paralelos com Java (Maven)](sample-parallel-test-java-maven.md)
+ [Configurar testes paralelos com Javascript (Jest)](sample-parallel-test-javascript.md)
+ [Configurar testes em paralelo com o Kotlin](sample-parallel-test-kotlin.md)
+ [Configurar testes em paralelo com o PHPUnit](sample-parallel-test-phpunit.md)
+ [Configurar testes em paralelo com o Pytest](sample-parallel-test-python.md)
+ [Configurar testes em paralelo com o Ruby (Cucumber)](sample-parallel-test-ruby-cucumber.md)
+ [Configurar testes em paralelo com o Ruby (RSpec)](sample-parallel-test-ruby.md)
# Configurar testes em paralelo com o Django
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o Django em uma plataforma 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'
```
O exemplo acima mostra o uso da variável de ambiente `CODEBUILD_CURRENT_SHARD_FILES`. Aqui, `CODEBUILD_CURRENT_SHARD_FILES` é usado para obter caminhos de arquivos em notação com pontos compatíveis com o Django. Use `CODEBUILD_CURRENT_SHARD_FILES` entre aspas duplas, conforme mostrado acima.
# Configurar testes em paralelo com o Elixir
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o Elixir em uma plataforma 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"
```
# Configurar testes em paralelo com o Go
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o Go em uma plataforma 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"
```
No exemplo acima, a função `calculator.go` contém funções matemáticas simples para testar e todos os arquivos de teste e arquivos `calculator.go` estão dentro da pasta `calc`.
# Configurar testes paralelos com Java (Maven)
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o Java em uma plataforma 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"
```
No exemplo fornecido, a variável de ambiente `CODEBUILD_CURRENT_SHARD_FILES` contém arquivos de teste no fragmento atual, separados por quebras de linha. Esses arquivos são convertidos em uma lista separada por vírgulas de nomes de classes no formato aceito pelo parâmetro `-Dtest` do Maven.
# Configurar testes paralelos com Javascript (Jest)
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o Javascript em uma plataforma 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'
```
# Configurar testes em paralelo com o Kotlin
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o Kotlin em uma plataforma 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"
```
No exemplo acima, a CLI `codebuild-tests-run` é usada duas vezes. Durante a primeira execução, o kotlinc compila os arquivos. A variável `CODEBUILD_CURRENT_SHARD_FILES` recupera os arquivos de teste atribuídos ao fragmento atual, que são então convertidos em uma lista separada por espaços. Na segunda execução, o JUnit executa os testes. Novamente, `CODEBUILD_CURRENT_SHARD_FILES` busca os arquivos de teste atribuídos ao fragmento atual, mas dessa vez eles são convertidos em nomes de classe.
# Configurar testes em paralelo com o PHPUnit
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o PHPUnit em uma plataforma 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'
```
# Configurar testes em paralelo com o Pytest
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o Pytest em uma plataforma 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"
```
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o Pytest em uma plataforma 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"
```
No exemplo acima, a variável de ambiente `CODEBUILD_CURRENT_SHARD_FILES` é usada para buscar arquivos de teste atribuídos ao fragmento atual e passados como matriz para o comando pytest.
# Configurar testes em paralelo com o Ruby (Cucumber)
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o Cucumber em uma plataforma 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"
```
# Configurar testes em paralelo com o Ruby (RSpec)
Veja a seguir uma amostra de um `buildspec.yml` que mostra a execução de testes em paralelo com o RSpec em uma plataforma 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"
```