Narciso Cerezo

Tecnología y emprendizaje

Consideraciones de diseño con JUnit

Hace tiempo que no escribo en el blog, pero es que mi actual proyecto consume todo mi tiempo. No obstante, merece la pena, porque es el más importante que he emprendido profesionalmente hablando.
Pero vamos al grano...
Aunque todavía no he terminado de entrar en la dinámica del desarrollo guiado por pruebas, al estilo de XP, hace ya tiempo que estoy "infectado por los tests". No hay duda de que el tiempo que "pierdes" escribiendo los test con JUnit es un tiempo bien empleado, puesto que luego puedes tener la tranquilidad de que si los test funcionan es más que probable que todo funcione. De hecho es la única manera de poder hacer test de regresión sin apenas esfuerzo y estar totalmente seguro de que no has introducido un bug, ni siquiera uno inducido en un módulo que no has tocado.
Sin embargo, hay algunos tipos de componente sobre los que es más complicado hacer pruebas con JUnit, sin ir más lejos los EJB (sean del tipo que sean). En general todo lo que se ejecuta sobre un contenedor es complicado de probar puesto que no es sencillo emular en nuestros juegos de pruebas las situaciones reales a las que se enfrenta el código en el contenedor.
Actualmente estoy desarrollando una aplicacion J2EE, preparando el camino para que todo pueda funcionar con WebServices, que sea muy rápida, estable y segura (como todos ;-) ).
Como servidor de aplicaciones estoy utilizando JBoss, aunque cuando el tiempo me deje y esté más maduro probaré Geronimo.
En el dilema que me planteé incialmente sobre que utilizar de J2EE estaban los Entity Beans CMP e Hibernate. Al final ha ganado Hibernate por ser más fácil de probar con JUnit, más fácil de generar y distribuir, y mucho más cercano al verdadero desarrollo orientado a objetos. Podría utilizar Entity Beans BMP que a su vez utilizaran Hibernate, pero me parece rizar el rizo e introducir complejidad innecesaria.
Sin embargo, si he decidido utilizar Stateless Session Beans, pues permiten distribuir la carga entre varios servidores de aplicaciones facilmente, pero sobre todo porque me permiten dejar el trabajo transaccional al contenedor y estar seguro de que se hace bien.
En este punto es donde de nuevo entra JUnit. Probar EJB, incluso Session Beans, es complicado. Así que al final, usar JUnit ha inducido una decisión de diseño importante, que puede implicar un pequeño coste adicional en tiempo de ejecución, pero cuyas ventajas creo que son superiores. Lo que estoy haciendo es que los Session Beans sean meros proxies de POJOs (que llamaré Business Objects) que son los que realmente tienen la lógica de negocio. Los BOs utilizan sessiones de Hibernate para realizar su trabajo, pero no realizan ningún tipo de asunción con respecto a las transacciones. De esta forma es sencillo realizar pruebas sobre los BOs fuera del contenedor, dejando que sean las clases de prueba las que manejen las transacciones de forma simple, y estar razonablemente seguros de que todo funcionará correctamente sobre el contenedor.
¿Te parece una buena solución? ¿Crees que hay una mejor?

En el próximo post detallaré el proceso de trabajo con Hibernate sobre JBoss, ya que a pesar del artículo al respecto que hay en la web de Hibernate, la realidad es algo diferente y además creo que sería muy conveniente detallar la integración del proceso con Ant, cosa que está explicada en varios sitios pero parcialmente en todos ellos.