Cuando llevamos a cabo un desarrollo guiado por pruebas (TDD) ideal, las pruebas serán escritas con antelación al código que deberá implementar la funcionalidad deseada, y a continuación se escribirá este último, de forma tal que supere aquellas. Es decir, como hemos comentado en varias ocasiones, las pruebas unitarias forman parte de las especificaciones de los requerimientos que deberemos cumplir. Sin embargo, este entorno ideal de iteraciones (escribir pruebas, codificar, pasar las pruebas y refactorizar) no siempre puede darse. En ocasiones, por limitaciones de tiempo se prima el que la funcionalidad esté lista sin llevar a cabo pruebas unitarias, o bien “heredamos” código ya implementado, y antes de meternos de pleno con él optamos por crear una batería de pruebas que nos ayude a programar con algo más de seguridad.
En casos como estos, es bastante útil contar con generadores de código que automaticen la creación de un “esqueleto” de pruebas unitarias. En el caso de usar el framework de pruebas MSTest de Microsoft, bastará con tener un Visual Studio para que, seleccionando los componentes a probar, genere un proyecto de pruebas unitarias que podremos “rellenar”. Incluso usando Pex podemos conseguir pruebas unitarias que validen casos extremos, ya que realiza un análisis de nuestro código. Por cierto, esta herramienta de Microsoft que aún está en alfa únicamente funciona con las ediciones Team System de Visual Studio.
Sin embargo, no siempre queremos o podemos usar el framework de pruebas que nos propone Microsoft. Bien por políticas de empresa, por licenciamiento, o porque preferimos cualquier otro, la generación de las pruebas para MSTest requiere realizar una serie de cambios sobre el código autogenerado, como renombrar atributos de clases y métodos y refactorizar un poco los fuentes. Si preferimos NUnit o MbUnit para implementar nuestras pruebas, podemos usar Doubler para, a partir de un ensamblado .NET, generar el esqueleto de pruebas unitarias de forma automática. Doubler está disponible en el sitio de Google Code, y se trata de un add-in para Lutz Roeder’s Reflector, que posiblemente conozcáis bien si soléis trabajar con .NET. Su instalación es muy sencilla (basta con añadir la DLL correspondiente desde el menú de gestión de add-ins), y permite acceder a un menú contextual desde el que le indicaremos qué deseamos hacer con una determinada clase. Desde el mismo podemos llevar a cabo diversas acciones:
- Generación de pruebas: Con botón derecho sobre un tipo inmediato, la generación de pruebas hace aparecer una lista de propiedades configurables (lenguaje de generación, framework de pruebas, que incluye MSTest, NUnit y MbUnit, inclusión de atributos…) para la generación automática de código de pruebas. Tras pulsar sobre el botón de generación (que es tan grande que no lo parece), se creará un fichero de código de pruebas que deberemos completar con los Asserts correspondientes.
- Grabación de un generador: Se aplica a tipo abstractos, creando un stub para las pruebas. Un Test Stub es un objeto usado en un tests para reemplazar al componente real. En nuestro caso, el Recording Test Stub puede ser usado para verificar salidas indirectas de las pruebas. En cierto modo es como crear un inspector de comportamiento para el componente que está siendo sometido a pruebas.
- Generador de Fakes: Crea un falso objeto, basado en una clase abstracta, para ser usado en las pruebas sobre una clase base. El falso objeto, o fake, deberá dar una implementación alternativa a la funcionalidad que el objeto al que reemplaza.
- Wrapper o generador de interfaces: Aplicado sobre un tipo inmediato, crea una copia de la interfaz del tipo seleccionado, así como una implementación de la misma que redirige todas las llamadas a una instancia privada del mismo a través. Esto permite un desacoplamiento de las pruebas respecto al objeto.
La verdad es que el código que crea es bastante claro y nos puede ahorrar, como decía tiempo y trabajo repetitivo con un par de clics de ratón. Si al mismo le sumamos que Pex también cuenta ya con un add-in para Reflector (y que funciona siempre que tengamos Pex instalado en nuestra máquina, es decir, si contamos con un Visual Studio TS), lo cierto es que la herramienta se va a convertir en un compañero aún más inseparable de lo que ya lo era.
A continuación muestro algunas capturas básicas con la generación de unos métodos de prueba para una clase muy simple, a modo de Hola Mundo con Doubler ;) .
Un par de bloques de nuestro código a probar...
La estructura de la DLL para Reflector.
El menú contextual añadido por el add-in Doubler.
Estableciendo las propiedades para el código generado
Y nuestro código de pruebas, listo para ser completado y usado.
