> For the complete documentation index, see [llms.txt](https://elguerre.gitbook.io/de0an/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://elguerre.gitbook.io/de0an/capitulo-6-la-construccion.-testeando-desde-el-principio/incluyendo-pruebas-en-las-builds.md).

# Incluyendo pruebas en las Builds

En el capítulo 4 ya vimos cómo configurar una build. En este apartado veremos cómo incluir los tests en las builds, para que puedan ejecutarse de manera automática.

A medida que continuamos desarrollando, si algo deja de funcionar, serán las builds quienes nos informen de ello, así, en todo momento nuestra aplicación estará lista para ser distribuida con la calidad esperada. El uso de integración continua (CI) nos asegura esta calidad tras cada *Check-in*. Bastará con habilitar la opción en la configuración tal y como muestra la figura 38.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-bac266991ea64d321407050efb17653563cb0b80%2Fimage48.png?alt=media)

**Figura 28.- Habilitar integración continua en VSTS**

VSTS nos ofrece 240 minutos gratuitos mensuales con una duración máxima para cada build de 30 minutos. Por ello, optaremos por integración continua como recomendación teniendo siempre presente dicha limitación para no agotar este crédito gratuito. Para comprobar el consumo, consultar la página: **.**

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-78a5c4195a83492e1e296931caff969a39f135cf%2Fimage49.png?alt=media)

**Figura 29.- Limitaciones por uso de Builds**

Para incluir los test en las builds llevaremos a cabo los siguientes pasos:

1. Acceder a la definición de la build “Task\[in] NB”.
2. Añadir un nuevo paso o tarea (“+ Add Task”) seleccionando de la lista resultante “Visual Studio Test”.
3. Configurar los siguientes parámetros:
   1. Marcar la cobertura de código
   2. El resto de valores mantenerlos con los valores predeterminados.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-e627d16b0e3201f7379c7d08e4725ab964bdba1a%2Fimage50.png?alt=media)

**Figura 30.- Inclusión de nuevo paso en la build "Task\[in] NB" para Test**

Una vez configurada la build y una vez que la solución compila correctamente, lanzamos la build manualmente, para no tener que esperar a su horario programado. En la figura 13, podemos apreciar el resultado de la build tras la ejecución de los tests así como su cobertura de código.

## Análisis de resultados

El resultado de cada ejecución de una build es almacenado (según la configuración de la política de retención, o “Retention Policy” de la build). Este resultado puede ser utilizado para mostrar informes de progreso. La siguiente imagen muestra un ejemplo.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-07e0536d9fdc80714ffe492ec9b9252abe740d52%2Fimage51.png?alt=media)

**Figura 31.- Diagramas con el resultado de las builds y la ejecución de Tests**

Dichos informes adquieren mayor importancia cuando se trabaja en equipo. En cualquier caso, van a permitirnos saber en cada momento y de manera gráfica y rápida la situación de cada una de las builds.