¿Cómo se manejan las pruebas de unidad/regresión que se espera que fallen durante el desarrollo?

Question

Durante el desarrollo del software, puede haber errores en la base del código que son problemas conocidos. Estos errores provocarán que las pruebas de regresión/unidad fallen, si las pruebas se han escrito bien.

Existe un debate constante en nuestros equipos sobre cómo deben gestionarse las pruebas fallan:

1. comentario a cabo su defecto casos de prueba con un comentario REVISIT o TODO.

   • Advantage: Siempre vamos a saber cuando un nuevo defecto ha sido introducido, y no uno que ya somos conscientes.
   • Desventaja: Puede olvidarse de REVISAR el caso de prueba comentado, lo que significa que el defecto podría deslizarse a través de las grietas.

2. Deje que fallen los casos de prueba.

   • Advantage: No se olvide de corregir los defectos, como los fallos de guión constantemente le recuerdan que está presente un defecto.
   • Desventaja: Difícil de detectar cuando se introduce un nuevo defecto, debido a un ruido de falla.

me gustaría explorar lo que son las mejores prácticas en este sentido. Personalmente, creo que una solución tri-estatal es la mejor para determinar si un script está pasando. Por ejemplo cuando se ejecuta una secuencia de comandos, se puede ver lo siguiente:

• Porcentaje pasado: 75%
• Porcentaje fallado (espera): 20%
• Porcentaje falló (inesperado): 5%

Básicamente marcaría cualquier caso de prueba que espere que falle (debido a algún defecto) con algunos metadatos. Esto garantiza que aún vea el resultado de la falla al final de la prueba, pero sepa inmediatamente si existe un nuevo error que no estaba esperando. Esto parece tomar las mejores partes de las 2 propuestas anteriores.

¿Alguien tiene alguna de las mejores prácticas para gestionar esto?

Answer 1

me gustaría dejar sus casos de prueba en mi experiencia, comentando código con algo así como

// TODO: fix test case 

es similar a hacer:.

// HAHA: you'll never revisit me 

Con toda seriedad, medida que se acerca a En el envío, el deseo de volver a visitar TODO en el código tiende a desvanecerse, especialmente con cosas como pruebas unitarias porque se está concentrando en arreglar otras partes del código.

Deje las pruebas tal vez con su solución de "tres estados". Sin embargo, recomendaría firmemente arreglar esos casos lo antes posible. Mi problema con los recordatorios constantes es que después de que las personas los ven, tienden a pasarlos por alto y dicen "oh, sí, obtenemos esos errores todo el tiempo ..."

Ejemplo: en algunos de nuestros códigos, hemos introducido la idea de "afirmaciones saltables", afirma que están ahí para hacerle saber que hay un problema, pero permiten que nuestros evaluadores pasen de ellas al resto del código. Hemos llegado a descubrir que QA comenzó a decir cosas como "oh sí, obtenemos esa afirmación todo el tiempo y nos dijeron que era omitible" y los errores no se informaron.

Supongo que lo que estoy sugiriendo es que hay otra alternativa, que es corregir los errores que encuentran sus casos de prueba inmediatamente. Puede haber razones prácticas para no hacerlo, pero entrar en ese hábito ahora podría ser más beneficioso a largo plazo.

Answer 2

Tiendo a dejar esto en, con un atributo Ignore (esto es usando NUnit) - la prueba se menciona en el resultado de ejecución de prueba, por lo que es visible, con la esperanza de que no lo olvidemos. Considere agregar el ID del problema/ticket en el mensaje "ignorar". De esta forma, se resolverá cuando se considere que el problema subyacente está maduro; sería bueno corregir las pruebas fallidas de inmediato, pero a veces los pequeños errores deben esperar hasta que llegue el momento.

He considerado el atributo Explicit, que tiene la ventaja de poder ejecutarse sin una recompilación, pero no requiere un argumento de "razón", y en la versión de NUnit que ejecutamos, la prueba no aparece en la salida como unrun.

Answer 3

Hicimos lo siguiente: Establezca una jerarquía en las pruebas.

Ejemplo: Tienes que probar 3 cosas.

• Prueba el inicio de sesión (login, recuperar el nombre de usuario, obtener la "última fecha de inicio de sesión" o algo familiarizado etc.)
• prueba la recuperación de bases de datos (búsqueda de un "schnitzelmitkartoffelsalat" dada - tag, buscar la últimas etiquetas)
• servicios web de prueba (conectar, obtener el número de versión, recuperar datos simples, recuperar datos detallados, el cambio de datos)

Cada punto de prueba tiene puntos secundarios, como se indica entre paréntesis. Dividimos estos jerárquicos. Tome el último ejemplo:

3. Connect to a web service 
    ... 
3.1. Get the version number 
    ... 
3.2. Data: 
    3.2.1. Get the version number 
    3.2.2. Retrieve simple data 
    3.2.3. Retrieve detailed data 
    3.2.4. Change data 

Si un punto de falla (mientras que el desarrollo) dará un mensaje de error exacto. Es decir. 3.2.2. ha fallado. Entonces la unidad de prueba no ejecutará las pruebas para 3.2.3. y 3.2.4. . De esta manera obtienes un mensaje de error (exacto): "3.2.2 falló". Dejando al programador resolver ese problema (primero) y no manejar 3.2.3. y 3.2.4. porque esto no funcionaría.

Eso ayudó mucho a aclarar el problema y aclarar lo que debe hacerse al principio.

Answer 4

Creo que necesita un observador TODO que produzca los comentarios "TODO" de la base de códigos. El TODO es sus metadatos de prueba.Es una línea frente al mensaje de error conocido y muy fácil de correlacionar.

TODO son buenos. Usalos, usalos a ellos. Gestione activamente al ponerlos en la cartera de trabajo de manera regular.

Answer 5

Generalmente trabajo en la prueba de Perl y Perl :: * módulos permiten insertar TODO bloques:

TODO: { 
    local $TODO = "This has not been implemented yet." 

    # Tests expected to fail go here 
} 

En la salida detallada de la prueba de funcionamiento, el mensaje en $ TODO se añade al pase/informe de fallas para cada prueba en el bloque TODO, para explicar por qué se esperaba que fallara. Para el resumen de los resultados de las pruebas, se considera que todas las pruebas TODO tuvieron éxito, pero, si alguna devuelve un resultado exitoso, el resumen también contará las mismas e informará el número de pruebas que tuvieron éxito inesperadamente.

Mi recomendación, entonces, sería encontrar una herramienta de prueba que tenga capacidades similares. (O simplemente utilizar Perl para su prueba, incluso si el código que está siendo probado es en otro idioma ...)

Answer 6

# 5 sobre Joel de "12 Steps to Better Code" está corrigiendo errores antes de escribir nuevo código:

Cuando se tiene un error en tu código que ves la primera vez que intentas ejecutarlo, podrás solucionarlo en un instante, porque todo el código aún está fresco en tu mente.

Si encuentra un error en algún código que escribió hace unos días, le llevará un tiempo buscarlo, pero cuando vuelva a leer el código que escribió, lo recordará todo y estará capaz de arreglar el error en un tiempo razonable.

Pero si encuentra un error en el código que escribió hace unos meses, probablemente haya olvidado muchas cosas sobre ese código, y es mucho más difícil de arreglar. En ese momento puede estar arreglando el código de otra persona, y pueden estar en Aruba de vacaciones, en cuyo caso, corregir el error es como ciencia: debe ser lento, metódico y meticuloso, y no puede estar seguro de cómo Cuánto tiempo llevará descubrir la cura.

Y si encuentra un error en el código que ya ha enviado, incurrirá en gastos increíbles para solucionarlo.

Pero si realmente desea ignorar las pruebas fallidas, utilice el atributo [Ignorar] o su equivalente en cualquier marco de prueba que utilice. En la salida HTML de MbUnit, las pruebas ignoradas se muestran en amarillo, en comparación con el rojo de las pruebas fallidas. Esto le permite notar fácilmente una prueba que falla recientemente, pero no perderá la pista de las pruebas de falla conocida.

Answer 7

Soluciona el error de inmediato.

Si es demasiado complejo para hacer de inmediato, es probable que sea una unidad demasiado grande para probar la unidad.

Pierde la unidad de prueba y coloca el defecto en tu base de datos de errores. De esta manera tiene visibilidad, se puede priorizar, etc.