Histórico de los resultados de Geb – Parte I

Introducción

Cuando se lanzan pruebas automáticas uno de los pasos posteriores a la ejecución suele ser el análisis de los resultados. Es importante comprobar que las pruebas se han lanzado correctamente y verificar la veracidad de los resultados tanto positivos como negativos detectando falsos positivos. Es por ello que mantener un histórico de los resultados puede llegar a ser muy interesante y nos ofrece grandes ventajas:

  • Comparativa frente a resultados anteriores
  • Detección de falsos positivos en base al histórico de los mismos
  • Ver la evolución de las pruebas
  • Ver el crecimiento de cobertura

Se pueden listar un mayor numero de ventajas que se nos puedan ocurrir, pero lo más importante es que mantener un histórico nos va a proporcionar una fuente de conocimiento de las ejecuciones que podremos consultar en un futuro.

Como he escrito en el título, vamos a extraer los datos de los resultados de Geb, que nos permite realizar pruebas funcionales integrándose en nuestro caso con Spock.

Vamos a ello.

Resultados de ejecución

Al ejecutar las pruebas los resultados de la ejecución por defecto se almacenan en el directorio:

[project]/target/test-reports/

Vamos a encontrarnos con los siguientes ficheros:

TESTS-TestSuites.xml: Fichero con los resultados de la ejecución del test suite por completo

TEST-functional-spock-[Spec].xml: Ficheros con los resultados de las ejecuciones de los Spec. Uno por cada spec que esté definido.

Html: Directorio donde se encuentran los resultados en formato html

En nuestro caso vamos a extraer los datos del fichero TESTS-TestSuites.xml.

Análisis para extracción del histórico de resultados

Hemos lanzado las pruebas del proyecto que vimos en el post https://qajungle.com/restful-api-functional-testing/ . El fichero de resultados, en este caso con resultados positivos:

De estos resultados se puede ir observando que disponemos de varios datos interesantes para extraer, vamos a categorizarlos como datos informativos y mediciones.

Datos test suites

Dentro del fichero de resultados se listan los test suites que han sido ejecutados, en este caso solo uno, veamos que datos interesantes nos aportan:

testsuite errors="0" failures="0" hostname="aritzaguila.local" id="0" name="PostsAPISpec" package="" tests="1" time="0.912" timestamp="2016-06-21T09:42:17"

Datos informativos
Los datos informativos nos van a servir para identificar correctamente la prueba que se ha ejecutado.

  • Hostname: Nombre del host donde que se ha ejecutado la prueba. Puede ser interesante siempre que ejecutemos las pruebas en diferentes máquinas o en caso de que las balanceemos.
  • Name: Nombre del Spec que se ha ejecutado.
  • Timestamp: Hora la que se ha ejecutado el Spec.

Datos medibles
Los datos medibles nos van a servir para ver, medir, comparar y evaluar los resultados de las pruebas.

  • Errors: Errores de ejecución de la prueba. Normalmente suelen ser debido a excepciones de ejecución.
  • Failures: Fallos de la prueba. Normalmente suelen ser fallos los incumplimientos de las pruebas.
  • Tests: Número de tests ejecutados correctamente.
  • Time: Tiempo de ejecución del Spec, en milisegundos.

Datos test cases

Cada test suite dispondrá de los casos de prueba que se han ejecutado, en nuestro caso uno.

testcase classname="PostsAPISpec" name="check that the API returns all posts data" time="0.909"

Datos informativos

  • Classname: Nombre de la clase donde se encuentra el test case.
  • Name: Nombre del test case.

Datos medibles

  • Time: TIempo de la ejecución del test case.
  • Name: Nombre del test case, en milisegundos.

Es muy importante recalcar que en caso de que haya habido un error o un failure en el caso de prueba se añadirá una nueva etiqueta con la información del error o el failure.

Ejemplo para error:

En el caso de un failure la etiqueta sería <failure>.

Enlaces a la serie de post

  1. Creando un histórico de los resultados de Geb – Parte II