PDF de programación - Clase 17. Prácticas: JUnit

Clase 17. Prácticas: JUnit

El marco Junit, que usted ha utilizado en este curso para probar su propio código, merece
ser objeto de estudio por su importancia. Fue desarrollado por Kent Beck y Erich Gamma.
Beck es muy conocido por su trabajo con patrones y con la programación XP (Extreme
Programming); mientras que Gamma es coautor de un conocido libro sobre patrones de
diseño. Al ser JUnit código abierto, usted podrá estudiar el código fuente por su cuenta.
Hay también un buen artículo aclaratorio en la distribución de JUnit, titulado ‘A Cook’s
Tour’, que explica el diseño de JUnit desde la perspectiva de los patrones de diseño y del
cual se ha extraido la mayor parte del material para esta clase.

JUnit ha tenido un gran éxito. Martin Fowler, un autor lúcido y con un marcado sentido
práctico, defensor de los patrones de diseño y de XP (y también autor de un excelente libro
sobre modelos de objeto llamado Analysis Patterns), dice sobre JUnit:

Jamás, en el campo del desarrollo de software, tantas personas han debido tanto a tan
pocas líneas de código.


Sin duda, la popularidad de JUnit se debe en gran parte a su facilidad de uso. Cabría pensar
que, ya que se trata de un marco que no hace gran cosa –simplemente ejecuta un grupo de
pruebas e informa de sus resultados– JUnit debería ser muy sencillo. Pero, en realidad, el
código es bastante complicado. La razón principal de su complejidad radica en que ha sido
ideado como un marco, para ampliarse de diversas formas no previstas, por lo que está
lleno de patrones complejos y generalizaciones diseñadas con el fin de permitir a los
implementadores anular algunas partes del marco y preservar otras.

Otra influencia que añade complejidad al asunto es el deseo de que las pruebas resulten
fáciles de escribir. Para ello se utilizó una especie de truco técnico (hack), basado en la
técnica de reflexión, que convierte métodos de una clase en instancias individuales del tipo
Test. También se utilizó otra técnica que, en principio, parece excesiva. La clase abstracta
TestCase hereda de la clase Assert, que contiene unos cuantos métodos estáticos de
certificación, simplemente para que la invocación del método assert quede escrita sólo
como un comando assert (…), en lugar de Assert.assert (…). Está claro que de ninguna
manera TestCase es un subtipo de Assert, por lo que esta estructuración no tiene en realidad
mucho sentido, aunque en el fondo permite escribir de manera más sucinta el código
perteneciente a TestCase. Y, como todos los casos de prueba que el usuario escribe son
métodos de la clase TestCase, la técnica resulta bastante valiosa.

El uso de patrones es una actividad que requiere mucha pericia y motivación. Los patrones
clave que vamos a analizar son: Template Method, el patrón clave de la programación del
marco; Command, Composite, y Observer. Todos ellos se explican con detenimiento en
Gamma et al, y, con la excepción de Command, ya se han visto en el presente curso.

Mi opinión personal es que el propio JUnit, la joya de la programación XP, desdice el

mensaje fundamental del movimiento XP: el código por sí mismo es suficiente para su
comprensión. JUnit es un ejemplo perfecto de programa que sería prácticamente
incomprensible sin que algunas representaciones globales del diseño se expliquen de
manera que se pueda entender el modo en que encajan. No resulta de gran ayuda el hecho
de que el código sea escaso en comentarios y que, cuando éstos existen, tiendan a ser
bastante oscuros. En este sentido, el artículo ‘Cook’s Tour’ es fundamental: sin él, llevaría
horas comprender las sutilezas de lo que sucede en el código. También sería de gran
utilidad tener más representaciones de diseño. El artículo presenta una visión simplificada,
y yo mismo tuve que construir un modelo de objeto que explica, por ejemplo, como
funciona el esquema de listeners.

Si es usted uno de esos estudiantes que no cree en las representaciones de diseño y que
piensa que el código es lo más importante, le recomiendo dejar de leer en este instante y
sentarse cómodamente en un sillón dispuesto a pasar toda la tarde con el código fuente de
JUnit. Quién sabe, tal vez cambie de idea…
Puede descargar el código fuente y documentación sobre JUnit de:

http://www.junit.org/.

Hay un almacén de código libre en la dirección:

http://sourceforge.net/projects/junit/

donde pueden verse (y añadirse) informes sobre fallos.

17.1 Resumen general

JUnit tiene diversos paquetes: framework como paquete básico de marcos, runner para
algunas clases abstractas y para la ejecución de pruebas, textui y swingui para interfaces de
usuario y extensions para algunas contribuciones prácticas al marco. Vamos a ocuparnos
principalmente del paquete de framework.

Los diagramas siguientes muestran el modelo de objeto y el diagrama de dependencia
modular. Es aconsejable que siga los diagramas a medida que lee el contenido de esta clase.
Ambos diagramas incluyen sólo los módulos del marco, aunque he incluido TestRunner en
el modelo objeto para demostrar cómo se conectan los listeners; sus relaciones, suite y
result, son variables locales de su método doRun.






Observe que el diagrama de dependencia modular está conectado casi por completo. No es
sorprendente si tenemos en cuenta que se trata de un marco, ya que los módulos no están
pensados para trabajar de forma independiente.

17.2 El patrón Command
El patrón Command encapsula una función como un objeto. De esta forma se implementa
un cierre –¿recuerdan el curso 6.001?– en un lenguaje orientado a objetos. La clase
command suele poseer un método único denominado do, run o perform. Se crea una
instancia de la subclase que anula este método, encapsulando también, normalmente, algún
estado de la clase (en el lenguaje del curso 6.001 llamábamos a esto el entorno del cierre).
El comando entonces puede pasar por un objeto y ‘ejecutarse’ invocando el método.

En JUnit, los casos de prueba se representan a través de objetos de comando que
implementan la interfaz
Test:
public interface Test { public

void run();

}

Casos de prueba verdaderos son instancias de una subclase de una clase concreta TestCase:
public abstract class TestCase implements Test {
private String fName; public TestCase(String
name) {

fName= name;

}



public void run() {

}

}

En realidad, el código actual no es así, pero empezar a partir de esta versión simplificada
nos permitirá explicar los patrones básicos más fácilmente. Observe que el constructor
asocia un nombre con el caso de prueba, lo que resultará útil al informar de los resultados.
De hecho, todas las clases que implementan Test tienen esta propiedad, lo que quizás
hubiera sido buena idea añadir el método

public String getName ()


a la interfaz Test. Observe también que los autores de JUnit utilizan la convención de que
los identificadores que comienzan por una f minúscula son campos de una clase (esto es,
variables de instancia). Veremos un ejemplo más elaborado del patrón command más
adelante, cuando estudiemos el programa Tagger.

17.3 Método Template
Puede determinarse que run sea un método abstracto, que exige, por tanto, que todas las
subclases lo superpongan. Pero la mayoría de los casos de prueba tienen tres fases:
determinación del contexto, ejecución de la prueba y desmontaje del contexto. Podemos
automatizar la utilización de esta estructura haciendo que run sea un método template:
public void run() {

setUp();
runTest();
tearDown();

}


Las implementaciones por defecto de los métodos hook no realizan ningún procesamiento:

protected void runTest() { } protected
void setUp() { } protected void
tearDown() { }


Están declaradas como protected, de forma que sean accesibles a partir de las subclases (y,

por consiguiente, se puedan superponer) pero no desde fuera del paquete. Estaría bien
poder restringir el acceso excepto a partir de las subclases, pero Java no ofrece dicho modo.
Una subclase puede superponer esos métodos arbitrariamente; si sólo superpone runTest,
por ejemplo, no habrá ningún comportamiento especial de los métodos setUp o tearDown.

Observamos el mismo patrón en la última clase, en las implementaciones organizadas en
jerarquías de esqueleto de la API de colecciones de Java. A este patrón a veces se le conoce
con el nombre, bastante cursi, de Hollywood Principle. Una API tradicional ofrece métodos
que son invocados por el cliente; un marco, por el contrario, hace llamadas a los métodos
de su cliente: ‘no nos llame, le llamaremos nosotros’..

El uso cada vez más extendido de las plantillas es la esencia de la programación de marcos.
Resulta sencillo y llama mucho la atención escribir programas que sean completamente
incomprensibles, pues las implementaciones de métodos realizan llamadas en todos los
niveles de la jerarquía de herencia.

Puede ser difícil saber qué esperar de una subclase en un marco. No se ha desarrollado una
analogía de las condiciones previas y subsiguientes, y la tecnología actual aún no está muy
desarrollada. Por lo general, es preciso leer el código fuente del marco para poder usarlo
eficazmente. La API de colecciones de Java es mejor que la mayoría de los marcos, ya que
incluye en las especificaciones de los métodos de plantilla descripciones exhaustivas sobre
su implementación. Esto se puede interpretar como una afrenta a la idea de especificación
abstracta, pero es inevitable en el contexto de un marco.



17.4 El patrón Composite