Quien siga mi labor como desarrollador debe recordar que nunca he sido muy fan de los test unitarios, no al menos de la forma que se suelen presentar porque sigo creyendo que realmente no valen para casi absolutamente nada. Otra cosa son los test de integración, o la creación de una serie de tests automatizados que se deben ejecutar periódicamente según vamos cambiando el código fuente para comprobar que dichos cambios no rompen la aplicación.

Os voy a hablar aquí de TDD para Aplicaciones Universales. Seguid leyendo.

También soy partidario de la verificación modular o de componentes. Es decir, tener alguna forma de poder verificar un conjunto de clases, o métodos de complejidad media o alta de forma independiente de la aplicación que las va a usar.

En mi faceta de desarrollador de sistemas de bajo nivel la cosa de comprobar funcionalidad es un poco complicada aunque siempre se puede hacer incluso cuando no hay sistemas automatizados para la realización de tests. Tan solo hay que tener la voluntad para idear sistemas, desde colocar un main() dentro de lo que quieras probar, hasta poner una cámara rodando y realizando un análisis de los fotogramas tomados.

En mi faceta de desarrollador de aplicaciones para Windows Phone, la cosa estaba bastante chunga al principio, sobre todo con Windows Phone 7.x, aunque con Visual Studio 2013 la cosa mejoró bastante, hasta el punto de disponer de un marco de verificación más o menos integrado.

La cosa va más o menos así: uno crea una nueva aplicación de UntTest en la solución en donde esté la aplicación que queremos verificar. Luego añade la referencia de la aplicación a la de UnitTest para finalmente ir creando los tests.

Con posterioridad a todo eso, cada vez que queramos ejecutar uno o varios tests, tan solo tenemos que irnos al menú contextual y lanzarlos. Se abrirá el emulador, se cargará la aplicación de test y estos se ejecutarán.

Para las aplicaciones de la tienda de Windows el proceso es idéntico, pero ahora el tipo de proyecto es el de “Librería de Tests Unitarios” o como quiera que se llame en español, en inglés es “Unit Test Library”.

—

Hasta aquí todo es muy bonito y chachi piruli juan pelotilla. Hasta que entraron las aplicaciones universales.

Recordemos en qué consiste este tipo de aplicaciones. Cuando creas una de ellas, Visual Studio te genera tres proyectos dentro de la solución, a saber: el proyecto para Windows 8.1, el de Windows Phone 8.1 y finalmente otro más con  la extensión “shared”, que es la parte común entre ambas plataformas y que debería contener el 99% de tu código.

Pues bien, poniéndolo en corto: no se pueden hacer tests unitarios de la parte compartida. No directamente al menos.

Sí, ya sé que es toda una ayuda al desarrollo, leedme de forma irónica el hecho de que no exista un interfaz directo para ello. Me dan igual los problemas técnicos, me da igual la excusa que puedan poner para no haberlo implementado.

A ver, cuando uno lanza los tests de una aplicación de la tienda, éstos se ejecutan sin más. Lo mismo pasa con Windows Phone, aunque en este caso se tenga que abrir el emulador y lanzar una aplicación.

¿Tan difícil hubiera sido modificar el framework y lanzar ambas cosas a la vez y poner dos columnas con el resultado de los mismos en ambas plataformas?

Parece ser que sí. Por eso lo de EDD. Volvamos al principio de la informática, a lanzarnos bits grabado en discos de piedra. En fin.

—

¿Podemos encontrar una solución a este problema? Claro que sí. Pasa por ejecutar los tests dos veces de forma manual.

El proceso a seguir es el mismo que si estuviéramos haciendo dos aplicaciones diferentes. Es decir, creamos un proyecto de UnitTest para Windows Phone 8.1 y otro para Windows 8.1, añadiendo la respectiva referencia de la aplicación a verificar.

¿Tenemos que repetir el código de los tests para cada plataforma? No. Aquí el truco está en hacer todos los tests en una plataforma y luego irnos a la otra y añadir los ficheros de test como referencias. Así cuando cambiemos/añadamos un test en un lugar se cambiará en el otro.

La mayor complicación de todo esto viene de hecho de que tenemos que andarnos con sumo cuidado sobre el proyecto que tendrá el código fuente de los tests y cuál las referencia.

Luego si os pasa como a mi, cada vez que lanzo una secuencia de tests, mi  Visual Studio se queda tonto cosa de un minuto y medio antes de responder y realizar los tests. Como lo que nos sobra a los programadores es el tiempo libre…