Gestionar falsos positivos en TDD o BDD

7

Soy relativamente nuevo en TDD y he estado pensando mucho sobre cómo administrar el conjunto de pruebas en constante crecimiento que viene con él.

Una de mis mayores preocupaciones es sobre falsos positivos.

En mi experiencia, no es infrecuente que una característica sufra cambios bastante masivos con el tiempo. Para implementar un cambio, primero escribiríamos una prueba (o muchas pruebas) para el nuevo comportamiento y luego codificaríamos el cambio. Idealmente, todas las pruebas pasarían una vez que el cambio de características se haya implementado correctamente.

¿Pero qué hay de las pruebas que cubrieron la primera encarnación de la característica? No hay garantía de que:

  1. todavía son relevantes;
  2. todavía pasan;
  3. su estado de aprobación / falla es correcto incluso.

La revisión / actualización / eliminación de estas pruebas en un grupo relativamente pequeño de pruebas puede ser manejable, pero ¿qué pasa cuando tienes miles o decenas de miles de pruebas? Me parece que hay un gran riesgo de que su colección de pruebas contenga muchos falsos positivos. Y, considerando que estas pruebas son una forma de documentación del sistema, ¡esto es bastante malo!

Pregunta: ¿Cómo mitiga el riesgo de acumular pruebas de Falso positivo al aplicar TDD o BDD (o cualquier cosa que finalmente lleve a una recopilación masiva de pruebas)?

    
pregunta MetaFight 17.12.2013 - 12:18

1 respuesta

11

La clave es que todas sus pruebas claramente se refieran a la funcionalidad precisa que deben probar.

Puede ser a través de nombres de prueba muy expresivos y una estricta disciplina de una aseveración por prueba, o una estructura de subdirectorios realmente inteligente en su conjunto de pruebas, o referencias de conjuntos de pruebas a código fuente, o lo que sea. El punto es que puede identificar rápidamente qué pruebas quedarán obsoletas.

Luego los borras.

Eso suena imprudente, pero cada cambio importante elimina alguna funcionalidad y la reemplaza por una funcionalidad nueva y diferente. Si está utilizando TDD, de todos modos va a escribir nuevas pruebas para cada parte de eso, y corregir las pruebas antiguas en lugar de seguir adelante con las nuevas pruebas y el código de producción es solo una pérdida de tiempo. ¡Y es por eso que las cuestiones de organización, acoplamiento, coherencia, etc. son tan importantes en el código de prueba como en el código de producción!

    
respondido por el Kilian Foth 17.12.2013 - 12:23

Lea otras preguntas en las etiquetas