En un post anterior, comente las nuevas caracteristicas de JUnit 4.4.
Ahi mecione que no le veia demasiado valor a los "Theories" que incorporó el framework. Debo adminitir que me equivoqué. Los estuve probando y ahora les veo dos cosas muy interesantes.
La primera es que es tipico tener casos donde hay una interfaz, luego una clase abstracta que implementa ciertos metodos y finalmente varias implementaciones. El problema que surgue con este esquema es: ¿Donde testeo los metodos que implementa la clase abstracta?. Mi solución a este problema siempre fue: o bien repetir los tests de estos metodos en los tests de unidad de cada clase concreta o bien usar un test abstracto y heredar los tests de las clases concretas de este test abstracto.
Los "theories" resuelven este problema de una forma muy elegante: cada clase concreta puede ser un "DataPoint" de un test con theories, y problema solucionado. Cuando se agrega una nueva clase concreta solo hay que agregarla como "DataPoint" (es una lastima que el meta modelo de Java no soporte el "allSubclasses" de Smalltalk).
Otra caracteristica que encontre importante es la de comunicación, usando la palabra "Theory" en lugar de test, se transmite muy bien la intención de "Programming as theory building".
Los unicos problemas que le veo a JUnit 4.x son: que todavía no tiene una buena integración con Eclipse, y que el uso excesivo de los import static es muy incomodo (estoy acostumbrado a usar organize imports asi que cada vez que tengo que usar uno de estos metodos estaticos que no use antes tengo que volver a escribir el import, horrible).
No hay comentarios.:
Publicar un comentario