¿Cómo mantienen las personas su conjunto de pruebas?

En particular, tengo curiosidad por los siguientes aspectos:

1. ¿Cómo sabe que sus casos de prueba son incorrectos (o están desactualizados) y necesitan ser reparados (o descartados)? Quiero decir, incluso si un caso de prueba se volviera inválido, podría pasar y permanecer en silencio, lo que podría hacerte creer falsamente que tu software funciona bien. Entonces, ¿cómo te das cuenta de estos problemas de tu conjunto de pruebas?

2. ¿Cómo sabe que su conjunto de pruebas ya no es suficiente y que se deben agregar nuevos casos de prueba? Supongo que esto tiene algo que ver con los cambios de requisitos, pero ¿hay algún enfoque sistemático para verificar la adecuación del conjunto de pruebas?

Respuesta corta: use herramientas conocidas que ayuden a mantener la calidad de los casos de prueba, como las siguientes herramientas de cobertura de código y calidad de código: Cobertura, PMD, Sonar, etc., que lo ayudarán a notar cuando un componente crítico del programa no se prueba lo suficiente. Además, escriba pruebas de integración, que es más probable que se rompan primero cuando algo sale mal.

Respuesta larga:

¿Cómo sabe que sus casos de prueba son incorrectos (o están desactualizados) y necesitan ser reparados (o descartados)? Quiero decir, incluso si un caso de prueba se volviera inválido, podría pasar y permanecer en silencio, lo que podría hacerte creer falsamente que tu software funciona bien. Entonces, ¿cómo te das cuenta de estos problemas de tu conjunto de pruebas?

• Usando herramientas de cobertura de código como Cobertura , puede detectar que los casos de prueba para una clase dada, o métodos complejos, ya no son suficientes. No necesita alcanzar una cobertura de código del 100% en todas partes y en la mayoría de los casos será difícil de lograr y no necesariamente útil; pero las pruebas para los aspectos más críticos de un programa deben mantenerse con un objetivo de al menos el 80% de la cobertura del código.
• Mediante el uso continuo de herramientas de integración y construcción , como Jenkins, que me gusta mucho, en combinación con el complemento Sonar , puede configurar activadores que envían correos electrónicos y otros tipos de alertas a las personas responsables de los últimos cambios. Diversos gráficos y estadísticas (Sonar también utiliza Cobertura entre muchas otras herramientas) ayudan a los revisores de códigos y desarrolladores de casos de prueba a centrarse en lo que es crítico.

¿Cómo sabe que su conjunto de pruebas ya no es suficiente y que se deben agregar nuevos casos de prueba? Supongo que esto tiene algo que ver con los cambios de requisitos, pero ¿hay algún enfoque sistemático para verificar la adecuación del conjunto de pruebas?

Lo que escribí para la primera pregunta es parte de la respuesta para su segunda pregunta. También agregaré los siguientes puntos aquí:

• Escriba casos de prueba de integración (o casos "comerciales" si lo prefiere) además de los casos de prueba. Es más probable que estos cambien / se rompan primero porque a menudo dependen de múltiples clases / métodos. Y dado que se rompen con frecuencia, es menos probable que se olvide. El único enfoque / metodología que, desde mi experiencia personal, ayuda a escribir buenas pruebas es Test-Driven Development . Particularmente si la persona que escribe el caso de prueba NO es la misma persona que escribe el código para él. Escribir buenos casos de prueba usando TDD también lleva tiempo, pero los resultados, al menos para mí, fueron extremadamente satisfactorios.
• Cada vez que salga un error, escriba la corrección y el caso de prueba que viene con él. El caso de prueba solo debe cubrir este error en particular. Como has cubierto completamente el código responsable del error, no debería volver a salir.

Realmente no hay ninguna manera de asegurarse de que sus casos de prueba sean correctos, excepto concentrándose realmente bien al crearlos: comprender el requisito, comprender el código y asegurarse de que estén de acuerdo. El objetivo de tener un conjunto de pruebas es que solo tiene que hacer esto una vez, y a partir de ese momento puede volver a ejecutar las pruebas y verificar que pasen, mientras que sin un conjunto de pruebas tendría que concentrarse realmente todo el tiempo , es decir, siempre que haga algo a su base de código. Pero el problema fundamental de tener que asegurarse de que estaba haciendo lo correcto en primer lugar sigue siendo que las computadoras simplemente no son lo suficientemente inteligentes como para liberarnos de esa tarea.

Por lo tanto, (1) si su conjunto de pruebas está incompleto, no hay una manera simple de ver eso. El análisis de cobertura de código puede probar que algunas líneas de código nunca se ejecutan, es decir, que el conjunto es deficiente de alguna manera, pero no cuán grave es esa deficiencia, y nunca puede probar que sea suficiente. Incluso con una cobertura de código del 100%, no tiene garantía de que todos los estados relevantesdel sistema se ejercen, y la cobertura estatal completa es imposible para cualquier sistema realista debido al número combinatorio de estados que podrían existir. Una buena técnica para asegurarse de que su caso de prueba sea al menos correcto para verificar lo que desea verificar es escribir la prueba, verificar que realmente falla, escribir / cambiar el código y luego verificar que ahora pasa. De ahí el entusiasmo por el desarrollo basado en pruebas: le permite estar bastante seguro de que una prueba individual hace lo correcto, y si crea toda su base de código de esa manera, puede obtener un nivel similar de confianza incluso en un sistema grande.

(2) Un conjunto de pruebas normalmente se vuelve insuficiente cada vez que cambian los requisitos; no tiene que adivinar. Si el cliente desea que se cambie un comportamiento particular, y sus pruebas tendrían éxito tanto antes como después del cambio, entonces claramente no estaban ejerciendo esa relación particular de entrada / salida.

En cuanto a los sistemas heredados que no tienen cobertura de prueba, o donde no sabes cuál es la cobertura, no hay prueba formal, pero (asesoramiento de los padres: ¡sigue la opinión personal!) Hablando por experiencia, es abrumadoramente probable que las pruebas No son adecuados. Cuando las pruebas se ven como una actividad posterior al hecho, opcional, que mejora la calidad pero no es realmente necesaria, tiende a ser incompleta y no sistemática porque el incentivo para asegurarse de que las pruebas sigan el código base simplemente no es ahí