unit testing - unit - ¿Qué necesitas de un arnés de prueba?

unit testing vs 2017

Question

Soy una de las personas involucradas en el grupo IETF Test Anything Protocol (TAP) (si está interesado, puede unirse a la lista de correo). Muchos lenguajes de programación están comenzando a adoptar TAP como su protocolo de prueba principal y quieren más de lo que ofrecemos actualmente. Como resultado, nos gustaría recibir comentarios de personas que tengan experiencia en xUnit, TestNG o cualquier otro marco / metodología de prueba.

Básicamente, aparte de un simple aprobado / reprobado, ¿qué información necesita de un arnés de prueba? Solo para darte algunos ejemplos:

• Nombre de archivo y número de línea (si corresponde)
• Hora de inicio y finalización
• Salida de diagnóstico, como la diferencia entre lo que recibió y lo que esperaba.

Y así ...

Answer 1

A lo que dijiste, agregaría:

• Método / función / nombre de clase
• Herramienta de conteo de cobertura, con excepciones (No cuente estos métodos)
• Resultado de N últimas carreras disponibles
• Ordene que las formas de analizar fácilmente los resultados de la prueba deben existir

Answer 2

Cualquier tipo de salida de diagnóstico, especialmente en caso de falla, es fundamental. Si falla una prueba, no desea tener que volver a ejecutar la prueba siempre debajo de un depurador para ver qué sucedió, debería haber algunos cluchos en la salida.

También me gusta ver una instantánea de antes y después de las variables críticas del sistema, como memoria o espacio en el disco duro disponible, ya que también pueden proporcionar excelentes pistas.

Finalmente, si está utilizando semillas aleatorias para cualquiera de las pruebas, escriba la semilla en el archivo de registro para que la prueba se pueda reproducir si es necesario.

Answer 3

Debe ser muy, muy fácil escribir una prueba e igualmente fácil de ejecutar. Eso, para mí, es la característica más importante de un arnés de prueba. Si alguien tiene que iniciar una GUI o pasar por un montón de aros para escribir una prueba, no la usarán.

Answer 4

Definitivamente todas las cosas de tu lista para cada artículo individual:

• Nombre del archivo
• Número de línea
• Nombre / clase / nombre de la función
• Cobertura de prueba
• Hora de inicio y hora de finalización
• Y / o tiempo total (esto sería más útil para mí que los dos elementos principales)
• Salida de diagnóstico, como la diferencia entre lo que recibió y lo que esperaba.

Desde lo más alto de mi cabeza no hay mucho más que el grupo de pruebas que me gustaría saber

• Nombre del grupo
• tiempo total de ejecución

Answer 5

Un conjunto arbitrario de etiquetas, por lo que puedo marcar una prueba como, por ejemplo, "integración, interfaz de usuario, administrador".

(Sabías que iba a pedir esto, ¿verdad ?-)

Answer 6

Me gustaría tener la capacidad de concatenar y anidar las transmisiones TAP.

Answer 7

Utilizo TAP como protocolo de salida para un conjunto de métodos simples de prueba C ++, y he visto las siguientes deficiencias:

• los pasos de la prueba no se pueden agrupar (solo existe la agrupación en varios scripts de prueba, pero para ejecutar todas las pruebas en nuestro software, necesito al menos un nivel más de agrupación, de modo que un solo paso de prueba se identifique como "Conexión de BD") "->" Prueba de reconexión "->" paso de prueba n. ° 3 ")
• ver las diferencias entre el producto esperado y el real es útil; Imprimo el diff en stderr (como comentario) o en realidad lanzo una herramienta gráfica diff
• el protocolo y las herramientas deben ser realmente independientes del lenguaje. Por ejemplo, hasta ahora solo conozco la herramienta "probar" de Perl para ejecutar pruebas, que se limita a ejecutar scripts Perl.

Al final, la salida de prueba debe ser adecuada como base para generar fácilmente un archivo de informe HTML que enumera pruebas exitosas de forma muy concisa, proporciona resultados detallados para pruebas fallidas y permite saltar rápidamente al IDE a la línea de prueba defectuosa.

Answer 8

Un ID único (uuid, md5sum) para poder identificar una prueba individual, por ejemplo, para usar al insertar resultados de prueba en una base de datos, o identificarlos en un rastreador de errores para posibilitar que QA vuelva a ejecutar una prueba individual.

Esto también permitiría rastrear el comportamiento de una prueba individual desde la compilación hasta la construcción a lo largo de todo el ciclo de vida de las revisiones múltiples de un producto. Esto podría eventualmente permitir correlaciones a gran escala entre eventos ''históricos'' (nuevas contrataciones, versiones de productos, actualizaciones de hardware) y los perfiles de las pruebas que fracasan como resultado de tales eventos.

También estoy pensando que TAP debe emitirse a través de un canal lateral dedicado en lugar de mezclarse con stdout. No estoy seguro de que esto esté bajo el alcance de la definición del protocolo.

Answer 9

• salida de color ascii opcional, verde para bien, amarillo para pendiente, rojo para errores

• la idea de que las cosas estén pendientes

• un resumen al final del informe de prueba de los comandos que ejecutarán las pruebas individuales donde

• Artículo de lista

  • algo salió mal

  • algo en la prueba estaba pendiente

Answer 10

Idea de extensión para TAP:

1..4
ok 1 - yay
not ok 2 - boo
ok 3 - yay #json:{...}
ok 4 - see my json

Posibilidad de adjuntar un comentario de #json ... - se puede ignorar con seguridad mediante el código existente - las etiquetas bien definidas se pueden reservar fácilmente en testanything.org - fáciles de producir, analizar y leer tipos complejos - yaml es un dolor