Amazon ya no CodeCatalyst está abierto a nuevos clientes. Los clientes existentes pueden seguir utilizando el servicio con normalidad. Para obtener más información, consulte [Cómo migrar desde CodeCatalyst](migration.md).
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.
# Pruebas con flujos de trabajo
En CodeCatalyst, puede ejecutar pruebas como parte de diferentes acciones de flujo de trabajo, como compilar y probar. Todas estas acciones del flujo de trabajo pueden generar informes de calidad. Una *acción de prueba* es una acción de flujo de trabajo que produce informes de prueba, cobertura de código, análisis de composición del software y análisis estático. Estos informes se muestran en la CodeCatalyst consola.
**Topics**
+ [Tipos de informes de calidad](#test-reporting)
+ [Cómo añadir la acción de prueba](test-add-action.md)
+ [Visualización de los resultados de una acción de prueba](test-view-results.md)
+ [Omisión de las pruebas fallidas en una acción](test.error-handling.md)
+ [Integrating universal-test-runner with](test.universal-test-runner.md)
+ [Configuración de informes de calidad en una acción](test-config-action.md)
+ [Prácticas recomendadas para las pruebas](test-best-practices.md)
+ [Propiedades de SARIF admitidas](test.sarif.md)
## Tipos de informes de calidad
La acción CodeCatalyst de prueba de Amazon admite los siguientes tipos de informes de calidad. Para ver un ejemplo sobre cómo dar formato a estos informes en YAML, consulte [Ejemplo de informes de calidad en YAML](test-config-action.md#test.success-criteria-example).
**Topics**
+ [Informes de pruebas](#test-reports)
+ [Informes de cobertura de código](#test-code-coverage-reports)
+ [Informes de análisis de composición de software](#test-sca-reports)
+ [Informes de análisis estático](#test-static-analysis-reports)
### Informes de pruebas
En CodeCatalyst, puedes configurar las pruebas unitarias, las pruebas de integración y las pruebas del sistema que se ejecutan durante las compilaciones. A continuación, CodeCatalyst puede crear informes que contengan los resultados de sus pruebas.
Puede utilizar un informe de prueba para solucionar los problemas relacionados con las pruebas. Si tiene muchos informes de pruebas de varias compilaciones, puede utilizar los informes de pruebas para ver los índices de error para optimizar mejor las compilaciones.
Puede utilizar los siguientes formatos de archivos de informes de pruebas:
+ Cucumber JSON (.json)
+ JUnit XML (.xml)
+ NUnit XML (.xml)
+ NUnit3 XML (.xml)
+ TestNG XML (.xml)
+ Visual Studio TRX (.trx, .xml)
### Informes de cobertura de código
En CodeCatalyst, puedes generar informes de cobertura de código para tus pruebas. CodeCatalyst proporciona las siguientes métricas de cobertura de código:
Cobertura de línea
Mide el número de instrucciones cubiertas por las pruebas. Solo comprende una sola instrucción, sin contar comentarios.
`line coverage = (total lines covered)/(total number of lines)`
Cobertura de ramificación
Mide cuántas ramificaciones cubren las pruebas de cada ramificación posible de una estructura de control, como una instrucción `if` o `case`.
`branch coverage = (total branches covered)/(total number of branches)`
Se admiten los siguientes formatos de archivo de informe de cobertura de código:
+ JaCoCo XML (.xml)
+ SimpleCov [JSON (generado por [simplecov, no por simplecov-json](https://github.com/simplecov-ruby/simplecov), .json)](https://github.com/vicentllongo/simplecov-json)
+ Clover XML (versión 3, .xml)
+ Cobertura XML (.xml)
+ LCOV (.info)
### Informes de análisis de composición de software
En CodeCatalyst, puede utilizar las herramientas de análisis de composición de software (SCA) para analizar los componentes de su aplicación y comprobar si hay vulnerabilidades de seguridad conocidas. Puede detectar y analizar informes de SARIF que detallen las vulnerabilidades de diversa gravedad y las formas de solucionarlas. Los valores de gravedad válidos, desde el más al menos grave, son `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` y `INFORMATIONAL`.
Se admiten los siguientes formatos de archivo de informe de SCA:
+ SARIF (.sarif, .json)
### Informes de análisis estático
Puede utilizar los informes de análisis estático (SA) para identificar los defectos del código fuente. En CodeCatalyst, puede generar informes de SA para ayudar a resolver problemas en su código antes de implementarlo. Entre estos problemas se incluyen errores, vulnerabilidades de seguridad, problemas de calidad y otras vulnerabilidades. Los valores de gravedad válidos, desde el más al menos grave, son `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` y `INFORMATIONAL`.
CodeCatalyst proporciona las siguientes métricas de SA:
Errores
Identifica una serie de posibles errores encontrados en su código fuente. Estos errores pueden incluir problemas relacionados con la seguridad de la memoria. A continuación se muestra un ejemplo de un error.
```
// The while loop will inadvertently index into array x out-of-bounds
int x[64];
while (int n = 0; n <= 64; n++) {
x[n] = 0;
}
```
Vulnerabilidades de seguridad
Identifica una serie de posibles vulnerabilidades de seguridad encontradas en su código fuente. Estas vulnerabilidades de seguridad pueden incluir problemas como el almacenamiento de los tokens secretos en texto sin formato.
Problemas de calidad
Identifica una serie de posibles problemas de calidad encontrados en su código fuente. Entre estos problemas de calidad pueden incluirse problemas relacionados con las convenciones de estilo. A continuación presentamos un ejemplo de un problema de calidad.
```
// The function name doesn't adhere to the style convention of camelCase
int SUBTRACT(int x, int y) {
return x-y
}
```
Otras vulnerabilidades
Identifica una serie de otras posibles vulnerabilidades encontradas en su código fuente.
CodeCatalyst admite los siguientes formatos de archivo de informes de SA:
+ PyLint (.py)
+ ESLint (.js, .jsx, .ts, .tsx)
+ SARIF (.sarif, .json)
# Cómo añadir la acción de prueba
Utilice el siguiente procedimiento para añadir una acción de prueba a su CodeCatalyst flujo de trabajo.
------
#### [ Visual ]
**Adición de una acción de prueba mediante el editor visual**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **Visual**.
1. Elija **Acciones**.
1. En **Acciones**, elija **Probar**.
1. En las pestañas **Entradas** y **Configuración**, complete los campos según sus necesidades. Para obtener una descripción de cada uno de los campos, consulte la [Acciones de compilación y prueba de YAML](build-action-ref.md). Esta referencia proporciona información detallada sobre cada campo (y el valor de la propiedad de YAML correspondiente) tal como aparece en el editor visual y el de YAML.
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
#### [ YAML ]
**Adición de una acción de compilación mediante el editor de YAML**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **YAML**.
1. Elija **Acciones**.
1. En **Acciones**, elija **Probar**.
1. Modifique las propiedades del código de YAML en función de sus necesidades. Encontrará una explicación de todas las propiedades disponibles en la [Acciones de compilación y prueba de YAML](build-action-ref.md).
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
## Definición de la acción de prueba
La acción de prueba se define como un conjunto de propiedades de YAML dentro del archivo de definición del flujo de trabajo. Para obtener más información sobre estas propiedades, consulte [Acciones de compilación y prueba de YAML](build-action-ref.md) en la [Definición de flujo de trabajo en YAML](workflow-reference.md).
# Visualización de los resultados de una acción de prueba
Utilice las instrucciones siguientes para ver los resultados de una acción de prueba, incluidos los registros, los informes y las variables generados.
**Visualización de los resultados de una acción de prueba**
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. En el diagrama de flujo de trabajo, elija el nombre de la acción de prueba, por ejemplo, **Prueba**.
1. Para ver los registros generados por una acción, seleccione **Registros**. Se muestran los registros de las distintas fases de acción. Puede expandir o contraer los registros según sea necesario.
1. Para ver los informes de prueba generados por la acción de prueba, seleccione **Informes** o, en el panel de navegación, elija **Informes**. Para obtener más información, consulte [Tipos de informes de calidad](test-workflow-actions.md#test-reporting).
1. Para ver la configuración de una acción de prueba, elija **Configuración**. Para obtener más información, consulte [Cómo añadir la acción de prueba](test-add-action.md).
1. Para ver las variables utilizadas por la acción de prueba, elija **Variables**. Para obtener más información, consulte [Uso de variables en flujos de trabajo](workflows-working-with-variables.md).
# Omisión de las pruebas fallidas en una acción
Si la acción tiene más de un comando de prueba, puede permitir que los siguientes comandos de prueba de la acción se ejecuten incluso aunque se produzca un error en uno de los comandos anteriores. Por ejemplo, en los siguientes comandos, puede que quiera que `test2` se ejecute siempre, incluso aunque `test1` falle.
```
Steps:
- Run: npm install
- Run: npm run test1
- Run: npm run test2
```
Normalmente, cuando un paso devuelve un error, Amazon CodeCatalyst detiene la acción del flujo de trabajo y la marca como fallida. Puede permitir que los pasos de la acción continúen ejecutándose redirigiendo el resultado del error a `null`. Puede hacerlo agregando `2>/dev/null` al comando. Con esta modificación, el ejemplo anterior tendría el siguiente aspecto.
```
Steps:
- Run: npm install
- Run: npm run test1 2>/dev/null
- Run: npm run test2
```
En el segundo fragmento de código, se respetará el estado del comando `npm install`, pero se ignorará cualquier error que devuelva el comando `npm run test1`. Como resultado, se ejecuta el comando `npm run test2`. De este modo, podrá ver ambos informes a la vez, independientemente de si se produce un error o no.
# Integrating universal-test-runner with
Las acciones de prueba se integran con la herramienta de línea de comandos de código abierto `universal-test-runner`. `universal-test-runner` utiliza el [protocolo de ejecución de pruebas](https://github.com/aws/universal-test-runner/blob/main/protocol/README.md) para ejecutar las pruebas en cualquier lenguaje de un marco determinado. `universal-test-runner` es compatible con los siguientes marcos:
+ [Gradle](https://gradle.org/)
+ [Jest](https://jestjs.io/)
+ [Maven](https://maven.apache.org/)
+ [pytest](https://pytest.org)
+ [.NET](https://learn.microsoft.com/en-us/dotnet/core/tools/)
`universal-test-runner` se instala solo en las imágenes seleccionadas para realizar acciones de prueba. Si configura una acción de prueba para usar un Docker Hub o Amazon ECR personalizados, debe instalar manualmente `universal-test-runner` para habilitar las características de prueba avanzadas. Para ello, instale Node.js (versión 14 o superior) en la imagen y después instale `universal-test-runner` mediante `npm` con el comando del intérprete de comandos `- Run: npm install -g @aws/universal-test-runner`. Para obtener más información sobre cómo instalar Node.js en el contenedor mediante comandos del intérprete de comandos, consulte [Installing and Updating Node Version Manager](https://github.com/nvm-sh/nvm#install--update-script).
Para obtener más información acerca del `universal-test-runner`, consulte [¿Qué es el universal-test-runner?](https://github.com/aws/universal-test-runner#-what-is-universal-test-runner)
------
#### [ Visual ]
**Para usar universal-test-runner en el editor visual**
1. Abra la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **Visual**.
1. Elija **Acciones**.
1. En **Acciones**, elija **Probar**.
1. En la pestaña **Configuración**, complete el campo de **Comandos del intérprete de comandos** actualizando el código de ejemplo con los marcos compatibles que haya elegido. Por ejemplo, para usar un marco compatible, debería usar un comando `Run` similar al siguiente.
```
- Run: run-tests
```
Si el marco que quiere usar no es compatible, considere la posibilidad de añadir un adaptador o un ejecutor personalizados. Para obtener una descripción del campo **Comandos del intérprete de comandos**, consulte [Steps](build-action-ref.md#build.configuration.steps).
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
#### [ YAML ]
**Para usar universal-test-runner en el editor YAML**
1. Abre la CodeCatalyst consola en [https://codecatalyst.aws/](https://codecatalyst.aws/).
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija el nombre del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **YAML**.
1. Elija **Acciones**.
1. En **Acciones**, elija **Probar**.
1. Modifique el código de YAML en función de sus necesidades. Por ejemplo, para usar un marco compatible, debería usar un comando `Run` similar al siguiente.
```
Configuration:
Steps:
- Run: run-tests
```
Si el marco que quiere usar no es compatible, considere la posibilidad de añadir un adaptador o un ejecutor personalizados. Para ver una descripción de la propiedad **Pasos**, consulte [Steps](build-action-ref.md#build.configuration.steps).
1. (Opcional) Seleccione **Validar** para validar el código de YAML del flujo de trabajo antes de confirmarlo.
1. Seleccione **Confirmar**, introduzca un mensaje de confirmación y vuelva a seleccionar **Confirmar**.
------
# Configuración de informes de calidad en una acción
En esta sección se describe cómo configurar un informe de calidad en una acción.
**Topics**
+ [Detección automática e informes manuales](#test.auto-discovery)
+ [Configuración de los criterios de éxito de los informes](#test.success-criteria)
+ [Ejemplo de informes de calidad en YAML](#test.success-criteria-example)
## Detección automática e informes manuales
Cuando la detección automática está habilitada, CodeCatalyst busca en todas las entradas transferidas a la acción y en todos los archivos generados por la propia acción, buscando informes de pruebas, cobertura de código, análisis de composición de software (SCA) y análisis estático (SA). Puede ver y manipular cada uno de estos informes en. CodeCatalyst
También puede configurar manualmente los informes que se generan. Puede especificar el tipo de informe que desea generar, así como el formato de archivo. Para obtener más información, consulte [Tipos de informes de calidad](test-workflow-actions.md#test-reporting).
## Configuración de los criterios de éxito de los informes
Puede establecer los valores que determinan los criterios de éxito de un informe de prueba, cobertura de código, análisis de composición de software (SCA) o análisis estático (SA).
Los criterios de éxito son umbrales que determinan si un informe se aprueba o no. CodeCatalyst primero genera el informe, que puede ser un informe de prueba, de cobertura de código, de SCA o SA, y, a continuación, aplica los criterios de éxito a los informes generados. A continuación, muestra si se han cumplido los criterios de éxito y en qué medida. Si algún informe no cumple los criterios de éxito especificados, la CodeCatalyst acción que especificó los criterios de éxito fallará.
Por ejemplo, al establecer los criterios de éxito del informe de SCA, los valores de vulnerabilidad válidos, que van del más al menos grave, son: `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` y `INFORMATIONAL`. Si establece los criterios para buscar una vulnerabilidad de gravedad `HIGH`, el informe fallará si hay al menos una vulnerabilidad de gravedad `HIGH` o no hay ninguna vulnerabilidad de gravedad `HIGH`, pero hay al menos una vulnerabilidad de un nivel de gravedad superior, como una vulnerabilidad de gravedad `CRITICAL`.
Si no especifica los criterios de éxito, ocurrirá lo siguiente:
+ El CodeCatalyst informe que se genere a partir de sus informes sin procesar no mostrará los criterios de éxito.
+ Los criterios correctos no se utilizarán para determinar si la acción de flujo de trabajo asociada se aprueba o no.
------
#### [ Visual ]
**Configuración de los criterios de éxito**
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija un flujo de trabajo que contenga una acción que genere un informe. Este es el informe al que quiera aplicar los criterios de éxito. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **Visual**.
1. En el diagrama de flujo de trabajo, elija la acción que ha configurado para generar CodeCatalyst informes.
1. Elija la pestaña **Salidas**.
1. En **Informes de detección automática** o en **Configurar informes manualmente**, elija **Criterios de éxito**.
Aparecen los criterios de éxito. En función de las selecciones anteriores, podría ver alguna de estas opciones o todas ellas:
**Índice de aprobación**
Especifique el porcentaje de pruebas en un informe de prueba que deben aprobarse para que el CodeCatalyst informe asociado se marque como aprobado. Los valores válidos son números decimales. Por ejemplo: `50`, `60.5`. Los criterios del índice de aprobación se aplican únicamente a los informes de pruebas. Para obtener más información sobre los informes de pruebas, consulte [Informes de pruebas](test-workflow-actions.md#test-reports).
**Cobertura de línea**
Especifique el porcentaje de líneas de un informe de cobertura de código que deben cubrirse para que el CodeCatalyst informe asociado se marque como aprobado. Los valores válidos son números decimales. Por ejemplo: `50`, `60.5`. Los criterios de cobertura de línea se aplican únicamente a los informes de cobertura de código. Para obtener más información sobre los informes de cobertura de código, consulte [Informes de cobertura de código](test-workflow-actions.md#test-code-coverage-reports).
**Cobertura de ramificación**
Especifique el porcentaje de ramificaciones de un informe de cobertura de código que deben cubrirse para que el CodeCatalyst informe asociado se marque como aprobado. Los valores válidos son números decimales. Por ejemplo: `50`, `60.5`. Los criterios de cobertura de ramificaciones se aplican únicamente a los informes de cobertura de código. Para obtener más información sobre los informes de cobertura de código, consulte [Informes de cobertura de código](test-workflow-actions.md#test-code-coverage-reports).
**Vulnerabilidades (SCA)**
Especifique el número máximo y la gravedad de las vulnerabilidades permitidas en el informe de la SCA para que el CodeCatalyst informe asociado se marque como aprobado. Para especificar las vulnerabilidades, debe especificar lo siguiente:
+ La gravedad mínima de las vulnerabilidades que desea incluir en el recuento. Los valores válidos, desde el más al menos grave, son `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` y `INFORMATIONAL`.
Por ejemplo, si elige `HIGH`, se contabilizan las vulnerabilidades `HIGH` y `CRITICAL`.
+ El número máximo de vulnerabilidades de la gravedad especificada que desea permitir. Si se supera este número, el CodeCatalyst informe se marca como fallido. Los valores válidos son números enteros.
Los criterios de vulnerabilidad se aplican únicamente a los informes de SCA. Para obtener más información acerca de los informes de SCA, consulte [Informes de análisis de composición de software](test-workflow-actions.md#test-sca-reports).
**Errores**
Especifique el número máximo y la gravedad de los errores permitidos en el informe de SA para que el CodeCatalyst informe asociado se marque como aprobado. Para especificar errores, debe especificar lo siguiente:
+ La gravedad mínima de los errores que desea incluir en el recuento. Los valores válidos, desde el más al menos grave, son `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` y `INFORMATIONAL`.
Por ejemplo, si elige `HIGH`, se contabilizan los errores `HIGH` y `CRITICAL`.
+ El número máximo de errores de la gravedad especificada que desea permitir. Si se supera este número, el CodeCatalyst informe se marcará como fallido. Los valores válidos son números enteros.
Los criterios de errores se aplican únicamente a PyLint los informes de ESLint SA. Para obtener más información acerca de los informes de SA, consulte [Informes de análisis estático](test-workflow-actions.md#test-static-analysis-reports).
**Vulnerabilidades de seguridad**
Especifique el número máximo y la gravedad de las vulnerabilidades de seguridad permitidas en el informe de SA para que el CodeCatalyst informe asociado se marque como aprobado. Para especificar las vulnerabilidades de seguridad, debe especificar lo siguiente:
+ La gravedad mínima de las vulnerabilidades de seguridad que desea incluir en el recuento. Los valores válidos, desde el más al menos grave, son `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` y `INFORMATIONAL`.
Por ejemplo, si elige `HIGH`, se contabilizan las vulnerabilidades de seguridad `HIGH` y `CRITICAL`.
+ El número máximo de vulnerabilidades de seguridad de la gravedad especificada que desea permitir. Si se supera este número, el CodeCatalyst informe se marca como fallido. Los valores válidos son números enteros.
Los criterios de vulnerabilidad de seguridad se aplican únicamente a PyLint los informes de ESLint SA. Para obtener más información acerca de los informes de SA, consulte [Informes de análisis estático](test-workflow-actions.md#test-static-analysis-reports).
**Problemas de calidad**
Especifique el número máximo y la gravedad de los problemas de calidad permitidos en el informe de SA para que el CodeCatalyst informe asociado se marque como aprobado. Para especificar problemas de calidad, debe especificar lo siguiente:
+ La gravedad mínima de los problemas de calidad que desea incluir en el recuento. Los valores válidos, desde el más al menos grave, son `CRITICAL`, `HIGH`, `MEDIUM`, `LOW` y `INFORMATIONAL`.
Por ejemplo, si elige `HIGH`, se contabilizan los problemas de calidad `HIGH` y `CRITICAL`.
+ El número máximo de problemas de calidad de la gravedad especificada que desea permitir. Si se supera este número, el CodeCatalyst informe se marca como fallido. Los valores válidos son números enteros.
Los criterios de calidad se aplican únicamente a PyLint los informes ESLint SA. Para obtener más información acerca de los informes de SA, consulte [Informes de análisis estático](test-workflow-actions.md#test-static-analysis-reports).
1. Elija **Confirmar**.
1. Ejecute su flujo de trabajo para CodeCatalyst aplicar los criterios de éxito a sus informes sin procesar y regenere los CodeCatalyst informes asociados con la información sobre los criterios de éxito incluida. Para obtener más información, consulte [Inicio manual de la ejecución de un flujo de trabajo](workflows-manually-start.md).
------
#### [ YAML ]
**Configuración de los criterios de éxito**
1. En el panel de navegación, elija **CI/CD** y, a continuación, elija **Flujos de trabajo**.
1. Elija un flujo de trabajo que contenga una acción que genere un informe. Este es el informe al que quiera aplicar los criterios de éxito. Puede filtrar por el nombre del repositorio de código fuente o la ramificación donde esté definido el flujo de trabajo, o bien por el nombre o el estado del flujo de trabajo.
1. Elija **Edit (Edición de)**.
1. Elija **YAML**.
1. En el diagrama de flujo de trabajo, elija la acción que ha configurado para generar CodeCatalyst informes.
1. En el panel de detalles, seleccione la pestaña **Salidas**.
1. En la acción, en la `AutoDiscoverReports` sección o en la `Reports` sección, añada una **SuccessCriteria**propiedad junto con `PassRate` `LineCoverage``BranchCoverage`,`Vulnerabilities`,`StaticAnalysisBug`,`StaticAnalysisSecurity`, y `StaticAnalysisQuality` propiedades.
Para obtener una explicación de cada una de estas propiedades, consulte la [Acciones de compilación y prueba de YAML](build-action-ref.md).
1. Elija **Confirmar**.
1. Ejecute su flujo de trabajo para CodeCatalyst aplicar los criterios de éxito a sus informes sin procesar y regenere los CodeCatalyst informes asociados con la información sobre los criterios de éxito incluida. Para obtener más información acerca del inicio de un flujo de trabajo, consulte [Inicio manual de la ejecución de un flujo de trabajo](workflows-manually-start.md).
------
## Ejemplo de informes de calidad en YAML
El siguiente ejemplo muestra cómo configurar manualmente cuatro informes: un informe de prueba, un informe de cobertura de código, un informe de análisis de composición de software y un informe de análisis estático.
```
Reports:
MyTestReport:
Format: JUNITXML
IncludePaths:
- "*.xml"
ExcludePaths:
- report1.xml
SuccessCriteria:
PassRate: 90
MyCoverageReport:
Format: CLOVERXML
IncludePaths:
- output/coverage/jest/clover.xml
SuccessCriteria:
LineCoverage: 75
BranchCoverage: 75
MySCAReport:
Format: SARIFSCA
IncludePaths:
- output/sca/reports.xml
SuccessCriteria:
Vulnerabilities:
Number: 5
Severity: HIGH
MySAReport:
Format: ESLINTJSON
IncludePaths:
- output/static/eslint.xml
SuccessCriteria:
StaticAnalysisBug:
Number: 10
Severity: MEDIUM
StaticAnalysisSecurity:
Number: 5
Severity: CRITICAL
StaticAnalysisQuality:
Number: 0
Severity: INFORMATIONAL
```
# Prácticas recomendadas para las pruebas
Cuando utilices las funciones de prueba que ofrece CodeCatalyst, te recomendamos que sigas estas prácticas recomendadas.
**Topics**
+ [Detección automática](#test.best-auto-discovery)
+ [Criterios de éxito](#test.best-success-criteria)
+ [Inclusión/exclusión de rutas](#test.best-include-exclude)
## Detección automática
Al configurar las acciones en CodeCatalyst, la detección automática le permite descubrir automáticamente los resultados de varias herramientas, como los informes de JUnit pruebas, y generar CodeCatalyst informes relevantes a partir de ellos. La detección automática ayuda a garantizar que los informes se sigan generando aunque cambien los nombres o las rutas de acceso a los resultados detectados. Cuando se añaden nuevos archivos, los descubre CodeCatalyst automáticamente y genera los informes pertinentes. Sin embargo, si utiliza la detección automática, es importante tener en cuenta algunos de los siguientes aspectos de esta característica:
+ Cuando se activa la detección automática en una acción, todos los informes del mismo tipo detectados automáticamente compartirán los mismos criterios de éxito. Por ejemplo, un criterio compartido, como un índice mínimo de aprobación, se aplicaría a todos los informes de pruebas detectados automáticamente. Si necesita criterios diferentes para informes del mismo tipo, debe configurar cada uno de estos informes de forma explícita.
+ La detección automática también puede encontrar los informes generados por sus dependencias y, si se han configurado criterios de éxito, es posible que la acción falle en estos informes. Este problema se puede solucionar actualizando la configuración de la ruta de exclusión.
+ No está garantizado que la detección automática produzca siempre la misma lista de informes, ya que analiza la acción en tiempo de ejecución. En el caso de que desee que siempre se genere un informe en particular, debe configurar los informes de forma explícita. Por ejemplo, si las pruebas se dejasen de ejecutar como parte de la compilación, el marco de pruebas no generaría ningún resultado y, en consecuencia, no se generaría ningún informe de prueba y la acción podría tener éxito. Si quiere que el éxito de la acción dependa de esa prueba en particular, debe configurar ese informe de forma explícita.
**sugerencia**
Al comenzar con un proyecto nuevo o existente, use la detección automática para todo el directorio del proyecto (incluya `**/*`). Esto invoca la generación de informes en todos los archivos del proyecto, incluidos los que se encuentren en los subdirectorios.
Para obtener más información, consulte [Configuración de informes de calidad en una acción](test-config-action.md).
## Criterios de éxito
Puede imponer umbrales de calidad en sus informes configurando criterios de éxito. Por ejemplo, si se han detectado automáticamente dos informes de cobertura de código, uno con una cobertura de línea del 80 % y el otro con una cobertura de línea del 60 %, tiene las siguientes opciones:
+ Establecer los criterios de éxito de la detección automática para la cobertura de la línea en un 80 %. Esto provocaría que se aprobara el primer informe y que el segundo no, lo que provocaría un error en la acción en general. Para desbloquear el flujo de trabajo, añada nuevas pruebas a su proyecto hasta que la cobertura de línea del segundo informe supere el 80 %.
+ Establecer los criterios de éxito de la detección automática para la cobertura de la línea en un 60 %. Esto haría que ambos informes se aprobaran, lo que provocaría que la acción tuviese éxito. A continuación, podría trabajar para aumentar la cobertura del código en el segundo informe. Sin embargo, con este enfoque, no se puede garantizar que la cobertura del primer informe no caiga por debajo del 80 %.
+ Configure de forma explícita uno o ambos informes mediante el editor visual o agregando una sección y una ruta de YAML explícitas para cada informe. Esto le permitiría configurar criterios de éxito independientes y nombres personalizados para cada informe. Sin embargo, con este enfoque, la acción podría fallar si las rutas de los informes cambian.
Para obtener más información, consulte [Configuración de los criterios de éxito de los informes](test-config-action.md#test.success-criteria).
## Inclusión/exclusión de rutas
Al revisar los resultados de las acciones, puede ajustar la lista de informes generados CodeCatalyst mediante la configuración `IncludePaths` y`ExcludePaths`.
+ `IncludePaths`Utilícelo para especificar los archivos y las rutas de archivo CodeCatalyst que desea incluir al buscar informes. Por ejemplo, si lo especifica`"/test/report/*"`, CodeCatalyst busca en el `/test/report/` directorio toda la imagen de creación utilizada por la acción. Cuando encuentra ese directorio, CodeCatalyst busca los informes en ese directorio.
**nota**
En el caso de los informes configurados manualmente, `IncludePaths` debe ser un patrón glob que coincida con un único archivo.
+ `ExcludePaths`Utilícelo para especificar los archivos y las rutas de archivo CodeCatalyst que desea excluir al buscar informes. Por ejemplo, si lo especifica`"/test/reports/**/*"`, no CodeCatalyst buscará archivos en el `/test/reports/` directorio. Para ignorar todos los archivos de un directorio, utilice el patrón glob `**/*`.
A continuación se muestran ejemplos de posibles patrones glob.
| Patrón | Description (Descripción) |
| --- | --- |
| `*.*` | Coincide con todos los nombres de objetos en el directorio actual que contienen un punto |
| `*.xml` | Coincide con todos los nombres de objetos en el directorio actual que terminan en `.xml` |
| `*.{xml,txt}` | Coincide con todos los nombres de objetos en el directorio actual que terminan en `.xml` o `.txt` |
| `**/*.xml` | Coincide con los nombres de objetos de todos los directorios que terminan en `.xml` |
| `testFolder` | Coincide con un objeto llamado `testFolder` y lo trata como un archivo |
| `testFolder/*` | Coincide con los objetos en un nivel de subcarpeta desde `testFolder`, como `testFolder/file.xml` |
| `testFolder/*/*` | Coincide con los objetos en dos niveles de subcarpeta desde `testFolder`, como `testFolder/reportsFolder/file.xml` |
| `testFolder/**` | Coincide con la subcarpeta `testFolder` así como con los archivos debajo de `testFolder`, como `testFolder/file.xml` y `testFolder/otherFolder/file.xml` |
CodeCatalyst interpreta los patrones globales de la siguiente manera:
+ El carácter de barra diagonal (`/`) separa los directorios en las rutas de los archivos.
+ El carácter asterisco (`*`) coincide con cero o varios caracteres de un componente de nombre sin superar límites de carpeta.
+ Un asterisco doble (`**`) coincide con cero o más caracteres de un componente de nombre en todos los directorios.
**nota**
`ExcludePaths` tiene prioridad sobre `IncludePaths`. Si tanto `IncludePaths` como `ExcludePaths` incluyen la misma carpeta, esa carpeta no se escanea en busca de informes.
# Propiedades de SARIF admitidas
El formato de intercambio de resultados de análisis estático (SARIF) es un formato de archivo de salida que está disponible en los informes de análisis de composición de software (SCA) y análisis estático en Amazon. CodeCatalyst En el siguiente ejemplo se muestra cómo configurar SARIF de forma manual en un informe de análisis estático:
```
Reports:
MySAReport:
Format: SARIFSA
IncludePaths:
- output/sa_report.json
SuccessCriteria:
StaticAnalysisFinding:
Number: 25
Severity: HIGH
```
CodeCatalyst admite las siguientes propiedades del SARIF, que se pueden utilizar para optimizar la forma en que aparecerán los resultados del análisis en sus informes.
**Topics**
+ [Objeto `sarifLog`](#test.sarif.sarifLog)
+ [Objeto `run`](#test.sarif.run)
+ [Objeto `toolComponent`](#test.sarif.toolComponent)
+ [Objeto `reportingDescriptor`](#test.sarif.reportingDescriptor)
+ [Objeto `result`](#test.sarif.result)
+ [Objeto `location`](#test.sarif.location)
+ [Objeto `physicalLocation`](#test.sarif.physicalLocation)
+ [Objeto `logicalLocation`](#test.sarif.logicalLocation)
+ [Objeto `fix`](#test.sarif.fix)
## Objeto `sarifLog`
| Name | Obligatorio | Descripción |
| --- | --- | --- |
| `$schema` | Sí | El URI del esquema JSON de SARIF para la versión [2.1.0](https://json.schemastore.org/sarif-2.1.0.json). |
| `version` | Sí | CodeCatalyst solo es compatible con la versión 2.1.0 de SARIF. |
| `runs[]` | Sí | Un archivo SARIF contiene una matriz de una o varias ejecuciones, en la que cada cual representa una ejecución única de la herramienta de análisis. |
## Objeto `run`
| Name | Obligatorio | Descripción |
| --- | --- | --- |
| `tool.driver` | Sí | Un objeto `toolComponent` que describe la herramienta de análisis. |
| `tool.name` | No | Una propiedad que indica el nombre de la herramienta utilizada para realizar el análisis. |
| `results[]` | Sí | Los resultados de la herramienta de análisis que se muestran en. CodeCatalyst |
## Objeto `toolComponent`
| Name | Obligatorio | Descripción |
| --- | --- | --- |
| `name` | Sí | El nombre de la herramienta de análisis. |
| `properties.artifactScanned` | No | Número total de artefactos analizados por la herramienta. |
| `rules[]` | Sí | Una matriz de objetos `reportingDescriptor` que representan reglas. Según estas reglas, la herramienta de análisis encuentra problemas en el código que se analiza. |
## Objeto `reportingDescriptor`
| Name | Obligatorio | Descripción |
| --- | --- | --- |
| `id` | Sí | El identificador único de la regla que se utiliza para hacer referencia a un resultado. Longitud máxima: 1024 caracteres |
| `name` | No | Nombre de visualización de la regla. Longitud máxima: 1024 caracteres |
| `shortDescription.text` | No | Descripción abreviada de la regla. Longitud máxima: 3000 caracteres |
| `fullDescription.text` | No | Descripción completa de la regla. Longitud máxima: 3000 caracteres |
| `helpUri` | No | Cadena que se puede localizar para que contenga el URI absoluto de la documentación principal de la regla. Longitud máxima: 3000 caracteres |
| `properties.unscore` | No | Un indicador que señala si se ha puntuado el resultado del análisis. |
| `properties.score.severity` | No | Un conjunto fijo de cadenas que especifican el nivel de gravedad del resultado. Longitud máxima: 1024 caracteres |
| `properties.cvssv3_baseSeverity` | No | Una calificación cualitativa de la gravedad según el [Common Vulnerability Scoring System v3.1](https://www.first.org/cvss/v3.1/specification-document). |
| `properties.cvssv3_baseScore` | No | Una puntuación base de CVSS v3 que oscila entre [0.0 y 10.0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.cvssv2_severity` | No | Si los valores de CVSS v3 no están disponibles, CodeCatalyst busca los valores de CVSS v2. |
| `properties.cvssv2_score` | No | Una puntuación base de CVSS v2 que oscila entre [0.0 y 10.0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.severity` | No | Un conjunto fijo de cadenas que especifican el nivel de gravedad del resultado. Longitud máxima: 1024 caracteres |
| `defaultConfiguration.level` | No | La gravedad predeterminada de una regla. |
## Objeto `result`
| Name | Obligatorio | Descripción |
| --- | --- | --- |
| `ruleId` | Sí | El identificador único de la regla que se utiliza para hacer referencia a un resultado. Longitud máxima: 1024 caracteres |
| `ruleIndex` | Sí | El índice de la regla asociada en el componente de la herramienta `rules[]`. |
| `message.text` | Sí | Un mensaje que describe el resultado y muestra el mensaje de cada resultado. Longitud máxima: 3000 caracteres |
| `rank` | No | Un valor comprendido entre 0.0 y 100.0, ambos inclusive, que representa la prioridad o la importancia del resultado. En esta escala se valora 0.0 como la prioridad más baja y 100.0 como la prioridad más alta. |
| `level` | No | La gravedad del resultado. Longitud máxima: 1024 caracteres |
| `properties.unscore` | No | Un indicador que señala si se ha puntuado el resultado del análisis. |
| `properties.score.severity` | No | Un conjunto fijo de cadenas que especifican el nivel de gravedad del resultado. Longitud máxima: 1024 caracteres |
| `properties.cvssv3_baseSeverity` | No | Una calificación cualitativa de la gravedad según el [Common Vulnerability Scoring System v3.1](https://www.first.org/cvss/v3.1/specification-document). |
| `properties.cvssv3_baseScore` | No | Una puntuación base de CVSS v3 que oscila entre [0.0 y 10.0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.cvssv2_severity` | No | Si los valores de CVSS v3 no están disponibles, CodeCatalyst busca los valores de CVSS v2. |
| `properties.cvssv2_score` | No | Una puntuación base de CVSS v2 que oscila entre [0.0 y 10.0](https://nvd.nist.gov/vuln-metrics/cvss). |
| `properties.severity` | No | Un conjunto fijo de cadenas que especifican el nivel de gravedad del resultado. Longitud máxima: 1024 caracteres |
| `locations[]` | Sí | El conjunto de ubicaciones en las que se detectó el resultado. Solo se debe incluir una ubicación, a menos que el problema solo se pueda corregir realizando un cambio en cada ubicación especificada. CodeCatalyst utiliza el primer valor de la matriz de ubicaciones para anotar el resultado. Número máximo de objetos `location`: 10 |
| `relatedLocations[]` | No | Una lista de ubicaciones adicionales a las que se hace referencia en el resultado. Número máximo de objetos `location`: 50 |
| `fixes[]` | No | Matriz de `fix` objetos que representan la recomendación proporcionada por la herramienta de digitalización. CodeCatalyst utiliza la primera recomendación de la `fixes` matriz. |
## Objeto `location`
| Name | Obligatorio | Descripción |
| --- | --- | --- |
| `physicalLocation` | Sí | Identifica el artefacto y la región. |
| `logicalLocations[]` | No | El conjunto de ubicaciones descritas por su nombre sin hacer referencia al artefacto. |
## Objeto `physicalLocation`
| Name | Obligatorio | Descripción |
| --- | --- | --- |
| `artifactLocation.uri` | Sí | El URI que indica la ubicación de un artefacto, normalmente un archivo en el repositorio o generado durante una compilación. |
| `fileLocation.uri` | No | El URI alternativo que indica la ubicación del archivo. Se usa si se devuelve `artifactLocation.uri` vacío. |
| `region.startLine` | Sí | El número de línea del primer carácter de la región. |
| `region.startColumn` | Sí | El número de columna del primer carácter de la región. |
| `region.endLine` | Sí | El número de línea del último carácter de la región. |
| `region.endColumn` | Sí | El número de columna del último carácter de la región. |
## Objeto `logicalLocation`
| Name | Obligatorio | Description (Descripción) |
| --- | --- | --- |
| `fullyQualifiedName` | No | Información adicional que describe la ubicación del resultado. Longitud máxima: 1024 caracteres |
## Objeto `fix`
| Name | Obligatorio | Description (Descripción) |
| --- | --- | --- |
| `description.text` | No | Un mensaje que muestra una recomendación para cada resultado. Longitud máxima: 3000 caracteres |
| `artifactChanges.[0].artifactLocation.uri` | No | El URI que indica la ubicación del artefacto que se debe actualizar. |