La integración continua con las pruebas es útil para asegurarse de que tiene el código "enviable" verificado todo el tiempo.

Sin embargo, es realmente difícil mantener un conjunto completo de pruebas y, a menudo, parece que la construcción tendrá errores de todos modos.

¿Cuántas pruebas debe tener para sentirse seguro en sus pruebas de canalización de CI? ¿Utiliza algún tipo de métrica para decidir cuándo hay suficientes pruebas?

En general

¿Cuándo tiene suficientes pruebas automáticas para confiar en su proceso de integración continua?

La respuesta probablemente se aclare si piensa en lo que quiere confiar. Finalmente, mapea 1-1; cada prueba te hace confiar en lo único que prueba:

• Las pruebas unitarias le dan la confianza de que una clase (o módulo) hace lo que se prueba.
• Las pruebas de integración le dan la confianza de que varias unidades trabajan juntas de la manera en que se prueban.
• Las pruebas de extremo a extremo le dan la confianza de que toda la aplicación hace una determinada cosa, tal como se describe en la prueba.

Por la forma en que formuló su pregunta, probablemente esté pensando en un sentido comercial general en este momento, por ejemplo:

Quiero estar seguro de que mi aplicación puede hacer X .

Entonces, escribe una prueba de extremo a extremo que intenta hacer X y comprueba si lo hace correctamente.

Más concreto

Todo eso es muy autorreferencial, pero eso es porque a eso se reduce. Simplemente no hay más que eso.

Por ejemplo, imagine que escribe una aplicación para crear recetas de cocina. Una característica es que, si agrega diferentes cantidades de varios tipos diferentes de queso, le da la temperatura y el tiempo correctos para que todos se derritan.

Por lo tanto, puede escribir una prueba unitaria para usted CheeseMeltCalculator, donde le da 100 g de Gouda y 200 g de queso Emmental, y luego verifica que la temperatura y el tiempo sean correctos. Eso significa que ahora puede estar seguro de que CheeseMeltCalculatorfunciona para 100 g de Gouda y 200 g de queso. Ahora, si repite esta prueba con 300 g de Gouda en lugar de 200 g, puede estar bastante seguro de que funciona correctamente para diferentes valores. Puede agregar pruebas para 0, -1y int.MaxValueg de Gouda para estar seguro de que el código no se dispara (o se dispara correctamente según lo previsto) para entradas extrañas.

Puede escribir una prueba de integración para verificar que CheeseMeltCalculatorestá incorporada correctamente en todo el proceso de cálculo de temperatura y tiempo de los alimentos. Si esto sale mal, pero las CheeseMeltCalculatorpruebas anteriores están bien, puede estar seguro de que el error está en otras calculadoras o en la forma en que se combinan los datos de diferentes calculadoras.

Y finalmente, puede escribir una prueba de principio a fin para crear una receta completa, y una de las cosas que verifica es la temperatura y el tiempo del resultado. Si los 2 niveles anteriores de pruebas están bien, pero no funciona bien, entonces puede estar seguro de que esas partes son correctas y el error es algo acerca de cómo se integra el cálculo de temperatura en la aplicación. Por ejemplo, tal vez la entrada del usuario no se transfiere correctamente.

Y finalmente , si todas esas pruebas están bien, entonces puede estar seguro de que " si agrega diferentes cantidades de varios tipos diferentes de queso, le dará la temperatura y el tiempo correctos para que todos se derritan "

Larga historia corta

El punto es que no puedes tener una prueba "funciona correctamente". Solo puede probar "Si hago X, Y sucede".

Sin embargo, esto es exactamente lo que debería estar en las especificaciones técnicas del proyecto. Una declaración como " si agrega diferentes cantidades de varios tipos diferentes de queso, le da la temperatura y el tiempo correctos para que todos se derritan " no solo le da al cliente expectativas claras sobre lo que hará el producto terminado, sino que también se puede cambiar en pruebas automatizadas.

información adicional

El usuario Richard agregó esta información en una edición:

Martin Fowler tiene un resumen muy agradable en su sitio web sobre las estrategias más comunes: https://martinfowler.com/articles/microservice-testing/

No quiero eliminar esto, pero quiero decir esto: en comparación con esta respuesta, no es un "resumen", sino una explicación mucho más profunda, con buenos gráficos y todo.

Mi consejo sería: si todo tiene sentido después de leer mi respuesta, ya está. Si las cosas aún no están claras, reserve un poco de tiempo y lea el artículo vinculado.

No hay una métrica que pueda calcular que le brinde la confianza que está buscando. La confianza se construye haciendo algo y luego triunfando o fracasando y aprendiendo algo de él.

La única "métrica" ​​que he encontrado que me da confianza en nuestra cobertura de prueba es:

1. Número de defectos encontrados en la producción.
2. ¿Puede refactorizar la base del código y confiar en su cobertura de prueba para detectar defectos de regresión?

Las pruebas automatizadas no son una bala de plata. Debe realizar un seguimiento de cuántos defectos de producción se encuentran durante cada ciclo de lanzamiento. Cuando este número baja, está entregando un mejor software. Las pruebas automatizadas y la integración continua son solo herramientas que utiliza para ofrecer un mejor software.

La única métrica que realmente puede medir es "¿Está entregando un mejor software?"

E incluso entonces, es subjetivo.

¿Cuándo tiene suficientes pruebas automáticas para confiar en su proceso de integración continua?

En la mayoría del entorno económico, no tendrá el presupuesto para implementar suficiente confianza (> 99%) pero debe administrar un presupuesto limitado: se trata de la relación costo / beneficio.

• Algunas pruebas automatizadas son baratas de implementar, algunas son extremadamente costosas.
• Dependiendo de su gestión de riesgos real , algunos riesgos deben cubrirse mediante pruebas, mientras que otros no.

Entonces, en realidad, las pruebas fáciles / baratas / riesgosas se implementarán, mientras que las pruebas costosas / improbables no.

Un objetivo secundario del desarrollo de software es crear una arquitectura que sea fácil / barata de probar (diseñar para probar mediante la aplicación de Test-driven_development ) para que las pruebas automatizadas sean asequibles.

Supongo que el principio de Pareto también se puede aplicar para el software mantenible / comprobable aquí: dice que al gastar un 20% más de dinero se obtiene un beneficio adicional del 80%. Para alcanzar el 20% más de beneficios restantes, debe gastar un 80% adicional de dinero.

Puede aplicar Test Metrics, como cobertura de código y cobertura de mutación, para mostrarle código fuente potencial no probado.

Pero incluso con una cobertura del 100%, no puede estar seguro de que su código esté libre de errores.

A la gerencia le gustan los codemetrics. Si la gerencia impone "cobertura de código> = 80%" mientras los desarrolladores no admiten / les gusta la prueba automatizada, hay formas de escribir código de prueba con alta cobertura que no pruebe nada que dé una falsa sensación de seguridad.

El truco aquí no es preocuparse por la cobertura completa, sino en administrar el riesgo de sus cambios.

Digamos que está utilizando su canalización para implementar exactamente la misma versión que ya está en producción: ¿cuál es el riesgo de error de regresión? Cero (porque no hay cambio).

Ahora, digamos que quiero cambiar un texto en una de las pantallas. Agregué la prueba para verificar que el texto ahora se muestra correctamente (supongamos, por el argumento, que es un texto REALMENTE importante). ¿Qué otras pruebas necesito para verificar que no haya errores de regresión? Siendo realistas ninguno ...

Por lo tanto, la cantidad de pruebas automáticas requeridas para cada lanzamiento no depende del tamaño de su aplicación, sino del tamaño de su cambio. Si está haciendo pequeños cambios de bajo riesgo, necesitará muchas menos pruebas para mitigar los riesgos.

Pero espere un minuto ... ¿esto no se alinea muy bien con el punto de CI y CD?

¡Sí! Al mantener todos sus cambios y deltas muy pequeños, está mitigando muchos de los riesgos de regresión a través del proceso en lugar de las pruebas. Lo que es más, la pregunta en realidad no se convierte en una cuestión de automatización (esa es solo la herramienta que usaremos), es simplemente una cuestión de prueba y apetito de riesgo. Olvídese de la automatización por completo, ¿qué pruebas ejecutaría contra un cambio para asegurarse de que un cambio no haya introducido problemas? La respuesta a esa pregunta no cambia de un proceso de prueba manual a un sistema de CI: la única ventaja es que muchas de esas pruebas de regresión pueden haberse desarrollado previamente en una funcionalidad anterior y CI lo alienta a realizar cambios más pequeños y seguros.

TLDR

Sus pruebas son para mitigar el riesgo del cambio. Una implementación con un delta de cero no tiene ningún riesgo y, por lo tanto, no conlleva ningún riesgo. Al mantener sus cambios pequeños, resulta mucho más fácil identificar las pruebas necesarias para validarlos: la reutilización de la automatización es una ventaja.

Es la misma métrica que cuando estás probando tu producto manualmente.

Prácticamente, es fácil identificar estas zonas de baja confianza: suponiendo que está enviando el producto, supongo que tiene algunos pasos manuales posteriores a la tubería que mejoran su confianza de ser enviables. Estas son las áreas que debe automatizar para mejorar la confianza en el proceso automático en sí.

Su automatización es un esfuerzo continuo. Crece y mejora a medida que su producto mejora. Un defecto es una razón para repensar su código, junto con retinking el CI. Y el lado positivo aquí es que, como se puede lograr la confianza en el producto en sí, también se puede lograr la confianza en la automatización.