JUnit test runners

0
9538

JUnit test runners.

0. Índice de contenidos.


1. Introducción

Cuando anotamos un test de JUnit con la anotación @RunWith o extendemos de una clase con dicha anotación, JUnit
invoca a la clase referenciada en la anotación para lanzar los tests en vez de al lanzador por defecto. El lanzador
por defecto es BlockJUnit4ClassRunner.

En este tutorial vamos a examinar los distintos runners que provee JUnit, out of the box, runners de terceros y veremos
cómo crear nuestros propios runners.


2. Entorno.

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 15′ (2.4 GHz Intel Core i7, 8GB DDR3 SDRAM).
  • Sistema Operativo: Mac OS X Lion 10.7.4
  • JUnit 4.10


3. JUnit Runners.

Podemos encontrar los siguientes runners dentro de la distribución de JUnit:


3.1. Suite.

Permite crear manualmente una suite que contenga tests de distintas clases. Las clases que forman parte de la suite
se incluyen en la anotación @Suite, que no solo indica las clases que se incluirán sino también el orden de ejecución
de los tests.


3.2. Parametrized.

Cuando anotamos una clase con @RunWith(Parametrized.class) se crearán tantas instancias y se ejecutarán tantas veces los
métodos de tests como parámetros devolvamos en el método anotado @Parameters

El método de test se invocará tantas veces como elementos hay dentro del array y, en la invocación tendremos los
valores de los mismos poblados en las variables de clase, si los inicializamos en el constructor de la misma.


3.3. Categories.

Las categorías sirven como cualificadores de nuestros tests de modo tal que nos permiten incluir o excluir en una suite
aquellos tests anotados con ciertos cualificadores.


4. Runners de terceros.

La mayoría de frameworks que implementan patrones creacionales de objetos, basándose en JUnit, proporcionan un
runner que permite disponer de dicho patrón dentro del entorno de la ejecución de tests de JUnit. A continuación
mostramos unos ejemplos aunque no son los únicos.


4.1. Spring.

Con el soporte del runner SpringJUnit4ClassRunner y la anotación @ContextConfiguration que indica los ficheros de configuración
de Spring que configuran el contexto en el ámbito de este test.


4.2. Arquilian.

Con el soporte del runner Arquilian.class y la anotación @Deployment que devuelve el paquete que contendrá
las clases que formarán parte del framework con el que correrá el test dentro del contenedor (CDI, ODGI,…).


4.3. Mockito.

Con el soporte del runner MockitoJUnitRunner y la anotación @Mock, mockito se encarga de crear un mock para los objetos anotados.


5. Nuestro propio runner.

Imagina que tenemos nuestro propio framework, que no se basa en ningún producto conocido o necesitamos
inicializar el contexto de acceso a base de datos que no descansa en ningún sistema de ORM estandar,
sino uno comercial que no tiene soporte para JUnit; podríamos dar soporte, desde arquitectura, creando un runner propio.

A continuación vamos a ver un ejemplo de cómo implementar nuestro propio runner para establecer un límite máximo
a la ejecución de un test unitario, de tal modo que un test fallará si no se ejecuta, por defecto, en menos de 500 milisegundos.

Ahora un test que hace uso del runner:

o a nivel de clase con una regla @Rule

Volviendo a nuestro runner, y basándonos en la misma filosofía vamos a afinar un poco más permitiendo redefinir el límite de time-out por defecto a través de una anotación.

Para ello, lo primero es crearnos la interfaz de la anotación:

Que nos permitirá indicar a nivel de clase el timeOut de todos los tests que corren con nuestro runner:

Para obtener el valor de timeOut establecido en la anotación debemos refactorizar nuestro runner para acceder a la
anotación a nivel de clase:

Aunque establezcamos el valor de timeOut en 1 segundo sigue sin pasar el test de la concatenación de cadenas 😉



7. Referencias.


8. Conclusiones.

Desde el punto de vista de arquitectura debemos proveer de las piezas de infraestructura necesarias no
solo para el entorno normal de ejecución y que estas sean lo más transparentes posibles al desarrollador,
sino también para el entorno de test.

Un saludo.

Jose

jmsanchez@autentia.com

Dejar respuesta

Please enter your comment!
Please enter your name here