Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Ejecución de pruebas paralelas en compilaciones por lotes
Se puede utilizar AWS CodeBuild para ejecutar pruebas paralelas en compilaciones por lotes. La ejecución de pruebas paralelas es un método de prueba en el que varios casos de prueba se ejecutan simultáneamente en diferentes entornos, equipos o navegadores, en lugar de ejecutarse secuencialmente. Este método puede reducir significativamente el tiempo total de ejecución de las pruebas y mejorar su eficiencia. En CodeBuild, puedes dividir tus pruebas en varios entornos y ejecutarlas simultáneamente.
Las principales ventajas de la ejecución de pruebas paralelas son:
1. **Tiempo de ejecución reducido**: pruebas que tardarían horas de forma secuencial pueden completarse en minutos.
1. **Mejor utilización de los recursos**: hace un uso eficiente de los recursos informáticos disponibles.
1. **Comentarios más rápidos**: la realización más rápida de las pruebas permite obtener comentarios más rápidamente a los desarrolladores.
1. **Rentable**: ahorra tiempo y costos de computación a largo plazo.
Al implementar la ejecución de pruebas paralelas se suelen considerar dos enfoques principales: entornos separados y multiproceso. Si bien ambos métodos buscan conseguir la ejecución de pruebas simultáneas, difieren significativamente en su implementación y efectividad. Los entornos separados crean instancias aisladas en las que cada conjunto de pruebas se ejecuta de forma independiente, mientras que el multiproceso ejecuta varias pruebas simultáneamente dentro del mismo espacio de proceso utilizando diferentes subprocesos.
Las principales ventajas de los entornos separados en comparación con el multiproceso son:
1. **Aislamiento**: cada prueba se ejecuta en un entorno completamente aislado, lo que evita la interferencia entre pruebas.
1. **Conflictos de recursos**: no hay competencia por recursos compartidos, algo que suele producirse en el multiproceso.
1. **Estabilidad**: es menos propenso a condiciones de carrera y a problemas de sincronización.
1. **Depuración más sencilla**: cuando fallan las pruebas, es más fácil identificar la causa, ya que cada entorno es independiente.
1. **Administración del estado**: administre fácilmente problemas de estado compartidos que afectan habitualmente a las pruebas multiproceso.
1. **Mejor escalabilidad**: puede agregar fácilmente más entornos sin complejidad.
**Topics**
+ [Support en AWS CodeBuild](#parallel-test-support)
+ [Habilitación de la ejecución de pruebas paralelas en compilaciones por lotes](parallel-test-enable.md)
+ [Uso del comando `codebuild-tests-run` de la CLI](parallel-test-tests-run.md)
+ [Uso del comando `codebuild-glob-search` de la CLI](parallel-test-glob-search.md)
+ [Acerca de la división de pruebas](parallel-test-splitting.md)
+ [Combine automáticamente informes de compilación individuales](parallel-test-auto-merge.md)
+ [Ejemplo de ejecución de pruebas paralelas para varios marcos de prueba](sample-parallel-test.md)
## Support en AWS CodeBuild
AWS CodeBuild proporciona un soporte sólido para la ejecución de pruebas en paralelo a través de su función de compilación por lotes, diseñada específicamente para aprovechar la ejecución de entornos separados. Esta implementación se alinea perfectamente con los beneficios de los entornos de pruebas aislados.
**Compilación por lotes con distribución de pruebas**
CodeBuildSu funcionalidad de compilación por lotes permite la creación de varios entornos de compilación que se ejecutan simultáneamente. Cada entorno funciona como una unidad completamente aislada, con sus propios recursos de computación, entorno de tiempo de ejecución y dependencias. A través de la configuración de compilación por lotes puede especificar cuántos entornos paralelos necesitan y cómo deben distribuirse las pruebas entre ellos.
**Prueba de CLI de partición**
CodeBuild incluye un mecanismo de distribución de pruebas integrado a través de su herramienta CLI`codebuild-tests-run`, que divide automáticamente las pruebas en diferentes entornos.
**Agregación de informes**
Uno de los puntos fuertes clave de su implementación CodeBuild es su capacidad para gestionar la agregación de los resultados de las pruebas sin problemas. Si bien las pruebas se ejecutan en entornos separados, recopila y combina CodeBuild automáticamente los informes de prueba de cada entorno en un informe de prueba unificado a nivel de compilación por lotes. Esta consolidación proporciona una vista integral de los resultados de las pruebas y, al mismo tiempo, mantiene los beneficios de eficiencia de la ejecución paralela.
El siguiente diagrama explica el concepto completo de ejecución de pruebas paralelas en AWS CodeBuild.
![\[Diagrama conceptual de la ejecución de pruebas paralelas.\]](http://docs.aws.amazon.com/es_es/codebuild/latest/userguide/images/parallel-test.png)
# Habilitación de la ejecución de pruebas paralelas en compilaciones por lotes
Para ejecutar pruebas en paralelo, actualice el archivo buildspec de compilación por lotes para incluir el campo build-fanout y el número de compilaciones paralelas para dividir el conjunto de pruebas en el campo `parallelism`, como se muestra a continuación. El campo `parallelism` especifica cuántos ejecutores independientes están configurados para ejecutar el conjunto de pruebas.
Para ejecutar las pruebas en varios entornos de ejecución paralela, establezca el campo `parallelism` en un valor mayor que cero. En el ejemplo siguiente, `parallelism` se establece en cinco, lo que significa que CodeBuild inicia cinco compilaciones idénticas que ejecutan una parte del conjunto de pruebas en paralelo.
Puede usar el comando [codebuild-tests-run](parallel-test-tests-run.md)CLI para dividir y ejecutar las pruebas. Los archivos de prueba se dividirán y una parte de las pruebas se ejecutará en cada compilación. Esto reduce el tiempo total necesario para ejecutar todo el conjunto de pruebas. En el siguiente ejemplo, las pruebas se dividirán en cinco y los puntos de división se calcularán en función del nombre de las pruebas.
```
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
```
Si los informes están configurados para compilar de forma dispersa, los informes de prueba se generan para cada compilación por separado, y se pueden ver en la pestaña **Informes** de las compilaciones correspondientes de la consola. AWS CodeBuild
Para obtener más información sobre cómo ejecutar pruebas paralelas por lotes, consulte [Ejemplo de ejecución de pruebas paralelas para varios marcos de prueba](sample-parallel-test.md).
# Uso del comando `codebuild-tests-run` de la CLI
AWS CodeBuild proporciona una CLI que tomará el comando de prueba y la ubicación del archivo de prueba como entrada. La CLI con estas entradas dividirá las pruebas en el número de particiones especificado en el campo `parallelism` basándose en los nombres de los archivos de prueba. La asignación de archivos de prueba a la partición se decide mediante la estrategia de partición.
```
codebuild-tests-run \
--files-search "codebuild-glob-search '**/__tests__/*.js'" \
--test-command 'npx jest --runInBand --coverage' \
--sharding-strategy 'equal-distribution'
```
En la siguiente tabla se describen los capos del comando `codebuild-tests-run` de la CLI.
| Nombre del campo | Tipo | Obligatorio u opcional | Definición |
| --- | --- | --- | --- |
| `test-command` | Cadena | Obligatorio | Este comando se usa para ejecutar las pruebas. |
| `files-search` | Cadena | Obligatorio | Este comando proporciona una lista de archivos de prueba. Puede utilizar el comando [codebuild-glob-search](parallel-test-glob-search.md)CLI AWS CodeBuild proporcionado o cualquier otra herramienta de búsqueda de archivos que prefiera. Asegúrese de que el comando `files-search` muestre los nombres de archivo, cada uno de ellos separado por una línea. |
| `sharding-strategy` | Enum | Opcional | Valores válidos: `equal-distribution`, (predeterminado), `stability` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/codebuild/latest/userguide/parallel-test-tests-run.html) Para obtener más información, consulte [Acerca de la división de pruebas](parallel-test-splitting.md). |
La `codebuild-tests-run` CLI trabaja primero para identificar la lista de archivos de prueba mediante el comando proporcionado en el parámetro `files-search`. A continuación, determina un subconjunto de archivos de prueba designados para la partición (entorno) actual mediante la estrategia de partición especificada. Por último, este subconjunto de archivos de prueba se formatea en una lista separada por espacios y se añade al final del comando proporcionado en el parámetro `test-command` antes de que se ejecute.
Para los marcos de prueba que no aceptan listas separadas por espacios, la `codebuild-tests-run` CLI proporciona una alternativa flexible a través de la variable de entorno `CODEBUILD_CURRENT_SHARD_FILES`. Esta variable contiene una lista separada por líneas de rutas de archivos de prueba designadas para la partición de compilación actual. Aprovechando esta variable de entorno, puede adaptarse fácilmente a varios requisitos del marco de pruebas y adaptarse a aquellos que requieren formatos de entrada diferentes de listas separadas por espacios. Además, también puede formatear los nombres de los archivos de prueba según las necesidades del marco de prueba. A continuación se ofrece un ejemplo de uso de `CODEBUILD_CURRENT_SHARD_FILES` en Linux con el marco Django. Aquí se usa `CODEBUILD_CURRENT_SHARD_FILES` para obtener rutas de archivo de *notación de puntos* compatibles con 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**
Tenga en cuenta que la variable de entorno `CODEBUILD_CURRENT_SHARD_FILES` solo se puede utilizar dentro del ámbito de la `codebuild-tests-run` CLI.
Además, si utiliza `CODEBUILD_CURRENT_SHARD_FILES` dentro de test-command, escriba `CODEBUILD_CURRENT_SHARD_FILES` entre comillas dobles como se muestra en el ejemplo anterior.
# Uso del comando `codebuild-glob-search` de la CLI
AWS CodeBuild proporciona una herramienta CLI integrada denominada `codebuild-glob-search` que le permite buscar archivos en el directorio de trabajo en función de uno o más patrones globales. Esta herramienta puede resultar especialmente útil cuando desee ejecutar pruebas en archivos o directorios específicos del proyecto.
## De uso
La `codebuild-glob-search` CLI tiene la siguiente sintaxis de uso:
```
codebuild-glob-search [ ...]
```
+ ``, ``, etc.: uno o más patrones globales para compararlos con los archivos del directorio de trabajo.
+ `*`: coincide con cualquier secuencia de caracteres (excepto los separadores de ruta).
+ `**`: coincide con cualquier secuencia de caracteres (incluidos los separadores de ruta).
**nota**
Asegúrese de que la cadena global vaya entre comillas. Para comprobar los resultados de la coincidencia de patrones, utilice el 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 generará una nueva lista de rutas de archivo separadas por líneas que coincidan con los patrones globales proporcionados. Las rutas de archivo devueltas serán relativas al directorio de trabajo.
Si no se encuentra ningún archivo que coincida con los patrones proporcionados, la CLI generará un mensaje que indica que no se ha encontrado ningún archivo.
Tenga en cuenta que los directorios que se encuentren debido a un patrón determinado se excluirán de los resultados de la búsqueda.
## Ejemplo
Si desea buscar solo archivos dentro del directorio tests y sus subdirectorios con extensión `.js`, puede usar el siguiente comando con la `codebuild-glob-search` CLI:
```
codebuild-glob-search '**/__tests__/*.js'
```
Este comando buscará todos los archivos con extensión `.js` dentro del directorio `__tests__` y sus subdirectorios, como indica el patrón.
# Acerca de la división de pruebas
La función de división de pruebas de AWS CodeBuild le permite paralelizar la ejecución del conjunto de pruebas en varias instancias de computación, lo que reduce el tiempo total de ejecución de las pruebas. Esta función se habilita mediante la configuración por lotes en los ajustes CodeBuild del proyecto y la `codebuild-tests-run` utilidad del archivo buildspec.
Las pruebas se dividen en función de la estrategia de fragmentación especificada. CodeBuild proporciona dos estrategias de fragmentación, tal como se especifica a continuación:
Equal-distribution
La estrategia de partición `equal-distribution` divide las pruebas en compilaciones paralelas por orden alfabético de los nombres de los archivos de prueba. Este método ordena primero los archivos de prueba y, a continuación, emplea un método basado en fragmentos para distribuirlos, lo que garantiza que archivos similares se agrupen para las pruebas. Se recomienda cuando se trata de un conjunto relativamente pequeño de archivos de prueba. Si bien este método tiene como objetivo asignar aproximadamente el mismo número de archivos a cada partición, con una diferencia máxima de uno, no garantiza la estabilidad. Cuando se agregan o quitan archivos de prueba en compilaciones posteriores, la distribución de los archivos existentes puede cambiar, lo que podría provocar una reasignación entre particiones.
Stability
La estrategia de partición `stability` emplea un algoritmo de hash coherente para dividir las pruebas entre particiones, lo que garantiza que la distribución de los archivos se mantenga estable. Cuando se agregan o eliminan nuevos archivos, este enfoque garantiza que las file-to-shard asignaciones existentes permanezcan prácticamente sin cambios. En el caso de conjuntos de pruebas de gran tamaño, se recomienda utilizar la opción de estabilidad para distribuir uniformemente las pruebas entre particiones. Este mecanismo tiene como objetivo proporcionar una distribución casi equitativa, lo que garantiza que cada partición reciba una cantidad similar de archivos, con una variación mínima. Si bien la estrategia de estabilidad no garantiza una distribución equitativa ideal, ofrece una distribución casi equitativa que mantiene la coherencia en las asignaciones de archivos entre las compilaciones, incluso cuando se agregan o eliminan archivos.
Para habilitar la división de pruebas, debe configurar la sección de lotes en los ajustes CodeBuild del proyecto, especificando el `parallelism` nivel deseado y otros parámetros relevantes. Además, deberá incluir la utilidad `codebuild-tests-run` en el archivo buildspec, junto con los comandos de prueba y el método de división adecuados.
# Combine automáticamente informes de compilación individuales
En las compilaciones por lotes distribuidas, AWS CodeBuild admite la fusión automática de informes de compilación individuales en un informe consolidado a nivel de lote. Esta característica proporciona una vista completa de los resultados de las pruebas y cobertura de código en todas las compilaciones de un lote.
## Funcionamiento
[Al ejecutar compilaciones `fanout` por lotes, cada compilación individual genera informes de prueba.](test-reporting.md) CodeBuild a continuación, consolida automáticamente los informes idénticos de diferentes compilaciones en un informe unificado, que se adjunta a la compilación por lotes. Se puede acceder fácilmente a estos informes consolidados a través del `reportArns` campo de la [ BatchGetBuildBatches](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_BatchGetBuildBatches.html#CodeBuild-BatchGetBuildBatches-response-buildBatches)API y también se pueden ver en la pestaña **Informes** de la consola. Esta capacidad de combinación se extiende también a los informes de detección automática.
Los informes consolidados se crean en [grupos de informes](test-report-group.md) que se especifican en la especificación de compilación o los detectan automáticamente. CodeBuild Puede analizar tendencias de los informes combinados directamente en estos grupos de informes, lo que proporciona información valiosa sobre el rendimiento general de la compilación y las métricas de calidad en compilaciones históricas del mismo proyecto de compilación por lotes.
Para cada compilación individual del lote, crea CodeBuild automáticamente grupos de informes independientes. Estos siguen una convención de nomenclatura específica que combina el nombre del grupo de informes de creación por lotes con un sufijo de `BuildFanoutShard`, donde el `shard_number` representa el número de partición en el que se crea el grupo de informes. Esta organización le permite realizar un seguimiento y analizar tendencias tanto en el nivel de compilación consolidada como individual, lo que proporciona flexibilidad a la hora de monitorear y evaluar sus procesos de compilación.
El informe de creación por lotes sigue la misma estructura que los [informes de compilación individuales](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_Report.html). Los siguientes campos clave de la pestaña **Informe** son específicos de los informes de compilación por lotes:
**Estado de informe de compilación por lotes**
El estado de los informes de creación por lotes sigue reglas específicas según el tipo de informe:
+ Informes de pruebas:
+ Correcto: el estado se establece como correcto cuando todos los informes de compilación individuales se han realizado correctamente.
+ Error: el estado se establece como fallido si ha fallado algún informe de compilación individual.
+ Incompleto: el estado se marca como incompleto si falta algún informe de compilación individual o tiene un estado incompleto.
+ Informes de cobertura de código:
+ Completo: el estado se establece como completo cuando se han completado todos los informes de compilación individuales.
+ Error: el estado se establece como fallido si ha fallado algún informe de compilación individual.
+ Incompleto: el estado se marca como incompleto si falta algún informe de compilación individual o tiene un estado incompleto.
**Resumen de pruebas**
El informe de prueba combinado consolida los siguientes campos de todos los informes de compilación individuales:
+ duration-in-nano-seconds: Tiempo máximo de duración de la prueba en nanosegundos entre todos los informes de compilación individuales.
+ total: recuento combinado de todos los casos de prueba, sumando el número total de pruebas de cada compilación.
+ status-counts: proporciona una vista consolidada de estados de las pruebas, como superadas, fallidas u omitidas, que se calcula sumando el recuento de cada tipo de estado en todas las compilaciones individuales.
**Resumen de cobertura de código**
El informe combinado de cobertura de código combina campos de todas las compilaciones individuales utilizando los siguientes cálculos:
+ branches-covered: suma de todas las ramificaciones cubiertas de informes individuales.
+ branches-missed: suma de todas las ramificaciones omitidas de informes individuales.
+ branch-coverage-percentage: `(Total covered branches / Total branches) * 100`
+ lines-covered: suma de todas las líneas cubiertas de informes individuales.
+ lines-missed: suma de todas las líneas omitidas de informes individuales.
+ lines-coverage-percentage: `(Total covered lines / Total lines) * 100`
**ID de ejecución**
ARN de compilación por lotes.
**Casos de prueba**
El informe combinado contiene una lista consolidada de todos los casos de prueba de compilaciones individuales, a la que se puede acceder a través de la [DescribeTestCases](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_DescribeTestCases.html)API y del informe de compilación por lotes de la consola.
**Coberturas de código**
El informe de cobertura de código combinado proporciona información consolidada sobre la cobertura de líneas y sucursales de cada archivo en todas las compilaciones individuales, a la que se puede acceder a través de la [DescribeCodeCoverages](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_DescribeCodeCoverages.html)API y del informe de compilación por lotes de la consola. Nota: En el caso de los archivos cubiertos por varios archivos de prueba distribuidos en diferentes particiones, el informe combinado sigue estos criterios de selección:
1. La selección principal se basa en la cobertura de línea más alta entre las particiones.
1. Si la cobertura de línea es igual en varias particiones, se seleccione la partición con mayor cobertura de ramificación.
# Ejemplo de ejecución de pruebas paralelas para varios marcos de prueba
Puede utilizar el comando `codebuild-tests-run` de la CLI para dividir y ejecutar pruebas en entornos de ejecución paralelos. En la siguiente sección, se proporcionan ejemplos de `buildspec.yml` para varios marcos que ilustran el uso del comando `codebuild-tests-run`.
+ Cada uno de los siguientes ejemplos incluye un nivel de `parallelism` de cinco, lo que significa que se crearán cinco entornos de ejecución idénticos para dividir las pruebas. Puede elegir un nivel de `parallelism` que se ajuste a su proyecto modificando el valor de `parallelism` en la sección `build-fanout`.
+ En cada uno de los ejemplos siguientes se muestra la configuración de las pruebas para que se dividan por nombre del archivo de prueba, que es el predeterminado. Esto distribuye las pruebas de manera uniforme entre los entornos de ejecución paralelos.
Antes de empezar, consulte [Ejecución de pruebas paralelas en compilaciones por lotes](parallel-test.md) para obtener más información.
Para obtener una lista completa de opciones al utilizar el comando `codebuild-tests-run` de la CLI, consulte [Uso del comando `codebuild-tests-run` de la CLI](parallel-test-tests-run.md).
**Topics**
+ [Configuración de pruebas paralelas con Django](sample-parallel-test-django.md)
+ [Configuración de pruebas paralelas con Elixir](sample-parallel-test-elixir.md)
+ [Configuración de pruebas paralelas con Go](sample-parallel-test-go.md)
+ [Configuración de pruebas paralelas con Java (Maven)](sample-parallel-test-java-maven.md)
+ [Configuración de pruebas paralelas con Javascript (Jest)](sample-parallel-test-javascript.md)
+ [Configuración de pruebas paralelas con Kotlin](sample-parallel-test-kotlin.md)
+ [Configuración de pruebas paralelas con PHPUnit](sample-parallel-test-phpunit.md)
+ [Configuración de pruebas paralelas con Pytest](sample-parallel-test-python.md)
+ [Configuración de pruebas paralelas con Ruby (Cucumber)](sample-parallel-test-ruby-cucumber.md)
+ [Configuración de pruebas paralelas con Ruby (Cucumber)](sample-parallel-test-ruby.md)
# Configuración de pruebas paralelas con Django
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con Django en una 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'
```
El ejemplo anterior muestra el uso de la variable de entorno `CODEBUILD_CURRENT_SHARD_FILES`. Aquí `CODEBUILD_CURRENT_SHARD_FILES` se usa para obtener rutas de archivo de notación de puntos de recuperación compatibles con Django. Use `CODEBUILD_CURRENT_SHARD_FILES` entre comillas dobles como se muestra arriba.
# Configuración de pruebas paralelas con Elixir
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con Elixir en una 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"
```
# Configuración de pruebas paralelas con Go
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con Go en una 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"
```
En el ejemplo anterior, la función `calculator.go` contiene funciones matemáticas simples para probar todos los archivos de prueba y el archivo `calculator.go` está en una carpeta `calc`.
# Configuración de pruebas paralelas con Java (Maven)
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con Java en una 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"
```
En el ejemplo dado, la variable de entorno `CODEBUILD_CURRENT_SHARD_FILES` contiene archivos de prueba en la partición actual, separados por líneas. Estos archivos se convierten en una lista de nombres de clases separados por comas en el formato aceptado por el parámetro `-Dtest` para Maven.
# Configuración de pruebas paralelas con Javascript (Jest)
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con Javascript en una 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'
```
# Configuración de pruebas paralelas con Kotlin
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con Kotlin en una 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"
```
En el ejemplo anterior, la `codebuild-tests-run` CLI se usa dos veces. Durante la primera ejecución, kotlinc compila los archivos. La variable `CODEBUILD_CURRENT_SHARD_FILES` recupera los archivos de prueba asignados a la partición actual, que luego se convierten en una lista separada por espacios. En la segunda ejecución, JUnit ejecuta las pruebas. Una vez más, `CODEBUILD_CURRENT_SHARD_FILES` recupera los archivos de prueba asignados a la partición actual, pero esta vez se convierten en nombres de clases.
# Configuración de pruebas paralelas con PHPUnit
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con PHPUnit en una 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'
```
# Configuración de pruebas paralelas con Pytest
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con Pytest en una 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"
```
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con Pytest en una 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"
```
En el ejemplo anterior, la variable de entorno `CODEBUILD_CURRENT_SHARD_FILES` se utiliza para recuperar los archivos de prueba asignados a la partición actual y pasarlos como matriz al comando pytest.
# Configuración de pruebas paralelas con Ruby (Cucumber)
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con Cucumber en una 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"
```
# Configuración de pruebas paralelas con Ruby (Cucumber)
A continuación se ofrece un ejemplo de `buildspec.yml` que muestra la ejecución de pruebas paralelas con RSpec en una 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"
```