¿Qué necesita de un arnés de prueba?

Question

Soy una de las personas involucradas en el Test Anything Protocol (TAP) IETF group (si está interesado, no dude en 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? Sólo para dar algunos ejemplos:

• nombre de archivo y número de línea (si es aplicable)
• inicio y de fin
• Salida de diagnóstico tales como la diferencia entre lo que era y lo que se esperaba.

Y así sucesivamente ...

Answer 1

Debe ser muy, muy fácil de escribir una prueba, e igualmente fácil para ejecutarlas. 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 2

Para lo que ha dicho que me gustaría añadir:

• nombre del método/función/clase
herramienta de conteo
• cobertura, con excepciones (No se cuenta estos métodos)
• Resultado de la N últimas carreras disponibles
• Mandato que deben existir maneras de analizar fácilmente los resultados de las pruebas

Answer 3

definitivamente todas las cosas de su lista para cada elemento individual:

• Nombre
• Número de línea
• nombre de espacio de nombres/clase/función
• Cobertura de la prueba
• hora de inicio y fin de los tiempos
• y/o el tiempo total (esto sería más útil para mí que los dos elementos superiores)
• Salida de diagnóstico como diferencia entre lo que obtienes y lo que esperabas

Desde la parte superior de mi cabeza no mucho más, pero para el grupo de pruebas que me gustaría saber

• nombre del grupo
• tiempo total de ejecución

Answer 4

Cualquier tipo de diagnóstico salida - especialmente en caso de fallo es crítico. 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 la memoria o el espacio en el disco duro disponible, ya que también pueden proporcionar excelentes pistas.

Finalmente, si usa 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 5

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

(que sabía que iba a pedir esto qué no :-)

Answer 6

me gustaría la posibilidad de concatenar y corrientes nido TAP.

Answer 7

utilizo TAP como protocolo de salida para un conjunto de sencilla C++ métodos de ensayo, y se han visto las siguientes deficiencias:

• pasos de prueba no se pueden poner en los grupos (sólo hay 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 identificará como "Conexión DB" -> "Prueba de reconexión" -> "paso 3 prueba")
• ver las diferencias entre el resultado esperado y real es útil; O 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 sé de la herramienta Perl "probar" 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 informe HTML archivo que enumera las pruebas exitosas de forma muy concisa, proporciona resultados detallados para las pruebas fallidas, y hace posible saltar rápidamente al IDE a la línea de prueba que falla.

Answer 8

Identificación única (uuid, md5sum) para poder identificar una prueba individual, por ejemplo, para insertar resultados de prueba en una base de datos o identificarlos en un rastreador de errores para que QA pueda volver a ejecutar una prueba prueba individual.

Esto también haría posible 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 mezclado con stdout. No estoy seguro de que esto esté bajo el alcance de la definición del protocolo.

Answer 9

• ascii salida opcional de color, verde para el bien, amarillo para la espera, rojo de errores

• la idea de las cosas que son pendientes

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

• elemento de la 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 anexar un comentario #JSON ... - puede ser ignorado con seguridad por el código existente - las etiquetas bien definidas se pueden reservar fácilmente en testanything.org - fácil de producir, analizar y leer tipos complejos - yaml es un dolor