Author: Germán Estévez
Completamos con esta entrada la serie sobre test unitarios, centrándonos en el Framework DUnitX, que es el que actualmente embarcadero recomienda y se incluye en las últimas versiones de Delphi.
- Test Unitarios; Introducción (Entrega 1)
- Test Unitarios; Framework DUnit (Entrega 2)
- Convertir Test de DUnit a DUnitX (Entrega 3)
- Test Unitarios; Framework DUnitX (Entrega 4)
INTRODUCCION
Como ya he comentado en las entradas anteriores, DUnitX es una evolución de DUnit (y que además recoge ideas de otros paquetes similares como NUnit). Si no lo tenéis en la versión actual de Delphi con la que estáis trabajando, podéis descargarlo desde el repositorio de Github, y deberíais poder instalarlo sin problemas. DUnitX soporta versiones de Delphi 2010 y posteriores.
A continuación os adjunto una tabla con las diferencias más significativas en cuanto a características que DUnitX nos aporta frente a DUnit. (click sobre ella para verla ampliada).
(fuente: DUnitX – A Unit Test Framework For Delphi)
Siguiendo con el ejemplo que hemos utilizado en las entradas anteriores, nuestro punto de partida es nuestra clase TAritmeticaBasica, cuya definición es la que se ve a continuación; Cuenta con 4 métodos que son los que vamos a testar:
Aquí podéis descargar la unit completa. Una versión con alguna codificación más que las que utilizamos en las otras entradas.
CREACIÓN DEL PROYECTO DE TEST (DUNITX)
Debemos rellenar como nombre de la clase TAritmeticaBasica, que es nuestra clase a testear.
Una vez aceptada esta pantalla, se nos genera un proyecto al que tenemos que añadir nuestra unit y que tendrá una estructura similar a esta (después de asignar un nombre y grabar).
Si compilamos y ejecutamos ya podemos ver el resultado de los test. Dado que hemos añadido métodos de ejemplo, podemos ver algunos resultados aunque sean de ejemplo.
En este caso estamos probando un proyecto de consola. Podemos comprobarlo revisando el fichero DPR y viendo que aparece el siguiente calificativo:
Si revisamos un poco por encima la unit TestX.UClass.TAritmeticaBasica.pas (que es como yo he llamado a la clase generada para los test) veremos que es similar a la generada por DUnit en las primeras entradas.
A continuación os pongo una imagen comparativa de ambas clases. En la parte izquierda la de DUnitX que acabamos de generar, à la derecha la de DUnit anterior.
Tenemos unos métodos de inicialización (que os he marcado con flechas) y que son equivalentes en ambos.
Lo que realmente considero importante es la parte que os he marcado en rojo en la imagen de la izquierda y cuyo comentario reza lo siguiente:
Test with TestCase Attribute to supply parameters.
Esto nos permite “salvar” el mayor inconveniente que nos habíamos encontrado con DUnit en la entrada anterior (Test Unitarios; Framework DUnit (Entrega 2)) que era poder parametrizar o poder definir parámetros para un Test.
El sistema de DUnitX nos hace mucho más fácil este trabajo y por ende, también la tarea de definir los test.
GENERAR CÓDIGO DE LOS TEST
Si tomamos como referencia la primera función de nuestra clase EsNumeroPrimo:
Y recordamos cómo eran los test generados con DUnit, teníamos lo siguiente:
Realmente con DUnit teníamos que hacerlo de esta manera (para hacer test independientes) u optar por la parametrización (programada por nosotros mediante clases). Con DUnitX ya se incluye un sistema de parametrización, de forma que nuestros test para esta clase estarán definidos de la siguiente forma:
Vemos que la diferencia es considerable.
En este caso tenemos un sólo test que podemos parametrizar y utilizar los atributos definidos con [TestCase] para asignar diferentes valores al test, y tener de esta forma virtualmente N test con una única definición (cosa más lógica que lo que habíamos visto).
La implementación del procedimiento es la siguiente:
Utilizo el método Assert.AreEqual para comprobar que el valor esperado es igual al que devuelve la función. Además podemos añadir como parámetro final un mensaje personalizado para el error.
Si cambiamos el resultado del Test_4 para que nos devuelva un error, en caso de no añadir mensaje obtendremos algo como esto:
Y en caso de añadir algún mensaje, podremos dar información añadida y que nos pueda resultar interesante a la hora de revisar los resultados.
En este caso he utilizado Assert.AreEqual, pero disponéis de muchas más funciones para utilizar en los test. En la DocWiki de embarcadero tenéis una lista detallada con las distintas funciones y una pequeña descripción de cada una de ellas, aunque los nombres ya son bastante descriptivos. En la imagen inferior podéis verlas:
Como podéis ver y tal como he comentado, los nombres son bastante explicativos de lo que hace cada una de ellas. Si queréis probar podéis modificar los ejemplos y el código propuesto para utilizar otras funciones y ver qué resultado obtenéis.
MODIFICADORES DE LOS TEST
Podemos llamarlos “Modificadores”, “Configuradores” o incluso “Decoradores” de los test. Me estoy refiriendo a las palabras entre corchetes que hemos colocado antes del procedimiento propio del test. Al principio de la entrada los hemos visto para definir los parámetros de la siguiente forma:
[TestCase(‘Test_2’, ‘2,True’)]
[TestCase(‘Test_3’, ‘3,True’)] …
También en el código de ejemplo los hemos visto acompañando a los métodos de Setup y TearDown, que nos permiten realizar inicializaciones y finalizaciones en la clase del test.
OTROS DECORADORES
Estos no son todos los que hay y en este final de la entrada vamos a repasar algunos de los que nos quedan disponibles y que podemos utilizar al definir los procedimientos de prueba.
[Ignore]
Nos permite ignorar (tal y como su nombre indica) la ejecución de un determinado test. por ejemplo, porque temporalmente no nos interesa o porque nos ha quedado obsoleto. Podemos añadir además un texto explicativo. A diferencia del que veremos a continuación, un test que ignoramos, nos parece como tal en los resultados.
El resultado que veríamos al usar el “ignored” será el siguiente:
[Test(False)]
Nos permite deshabilitar un determinado test, de forma que se ignora a la hora de ejecutar el proyecto de pruebas.
[RepeatTest(10)]
Si añadimos este modificador a un test, nos permitira ejecutarlo un número repetido de veces. Podemos ver un ejemplo simple a continuacion.
Podemos definir un procedimiento de test como el que se ve a continuacion>
Si ejecutamos el test una sola vez nos deber’ia fallar, pues el valor del contador valdr’a 1 y estamos utilizando la sentencia AreNotEqual.
[MaxTime(ms)]
Este atributo permite que el test se interrumpa (y devuelve un resultado de timeout) si el tiempo de ejecuciónnexcede del parámetro que se le pasa al “decorador” en milsegundos.
Un procedimiento como este (que tardará 5 segundos en ejecutarse):
Si se define en su cabecera de la siguiente manera:
Al cabo de 2 segundos finalizará y veremos un resultado como el siguiente:
Con esto concluyo esta entrada que debía ser la útima (aunque no será así). Me ha quedado una cosa en el tintero y prefiero dejarlo para la siguiente. Así que generaré un “bonus track”.
Os dejo algunos links interesantes, donde podéis encontrar más información:
- Documentación en formato web de la librería DUnitX
- Funciones a utilizar de la librería DUnitX (Embarcadero)
- Wiki de DUnitX en github
Y aquí tenéis el link al proyecto completo. Como siempre cualquier comentario, duda, crítica,… será bienvenido. Hasta la próxima.