Test Automáticos Web con JWebUnit
Supongo que todos habréis sufrido la sensación de frustración que se produce
cuando realizamos una entrega a nuestros usuarios de negocio y al realizar 4 «Clicks»
nos encuentra un error trivial o lo que es peor, un error que se había resuelto
en la entrega anterior…. y se desacredita totalmente nuestro esfuerzo. Esto
normalmente se produce por poca calidad y metodología (achacable a toda la
organización y no solo a los departamentos técnicos) a la hora de realizar
desarrollos informáticos.
Cuando construimos aplicativos complejos, hacer un cambio de
versión implica la realización de unas pruebas importantes de regresión para
asegurarnos de que lo que funcionaba seguía funcionando (aparte de lo nuevo
construido, claro está) y que tenemos capacidad de
asegurarlo de un modo inequívoco. Además es vital que podemos realizar la prueba de un modo
finito, completo y sistemático (acotado en el tiempo y sin dejarnos pruebas).
Si leéis sobre metodologías rápidas de desarrollo (tipo programación extrema)
comprobareis que uno de los principios básicos consiste en definir la prueba
unitaria (ver tutorial de JUnit) antes que el programa
en sí; Aparte de desacoplar la
lógica de negocio de la de presentación sin darnos cuenta, podemos probar en
segundos que cuando transferimos versiones entre entornos:
- No nos hemos olvidado fuentes o paquetes de clases de las que dependemos.
- No nos hemos olvidado de parámetros específicos del entorno
- Hemos cargado la base de datos (y estamos apuntando a la adecuada)
- Que cada vez más funcionalidades proporcionan las respuesta autónoma
adecuada - Que el mapping entre sistemas (front-end / back-end) es estable
- Y un largo etcetera.
Esto puede proporcionar un valor parcial ya que, en muchas ocasiones, lo que
nos interesa probar son conjuntos de transacciones desde el punto de vista de
usuario final y eso no se puede resolver con las pruebas unitarias comentadas
anteriormente (nos falta el contexto Web que puede ser la propia causa de los
problemas)
Necesitamos realizar pruebas simulando en comportamiento del usuario final
es decir, pruebas de caja negra (no nos importan los detalles internos sino que
queremos analizar únicamente los resultados del uso del sistema).
Hoy vamos a ver una opción gratuita llamada jWebUnit, que creo que os
va a gustar. Se basa en JUnit o otros paquetes gratuitos y, sin apenas
trabajo, podemos crear nuestros primeros test.
Descarga e Instalación
Podemos ir a la home del proyectos
http://jwebunit.sourceforge.net/
y acceder al binario.
Ocupa algo más de 2MBytes. Yo me he bajado la versión 1.2
La instalación es tan sencilla como descomprimirlo en un directorio.
Creación de un ejemplo
Es importante tener en cuenta las dependencias que tiene este proyecto a
otros, fundamentalmente a la hora de compilar y ejecutar nuestros casos de
prueba.
Nosotros vamos a usar NetBeans 3.6 para compilar y ejecutar nuestros
ejemplos. Creamos un nuevo proyectos
No se os olvide montar (con el botón derecho sobre el proyecto creado) los
ficheros jar necesarios. Los del producto:
Y los de los paquetes dependientes (colgando de lib)
Ahora creamos nuestro caso de prueba base (por el mecanismo de herencia)
import net.sourceforge.jwebunit.*;
public class testbasico extends WebTestCase {
public testbasico(String name) {
super(name);
}
public void setUp() {
getTestContext().setBaseUrl("https://adictosaltrabajo.com");
}
public void testHomeAdictos() {
beginAt("/");
this.assertTextPresent("El arquitecto J2EE");
this.dumpResponse(System.out);
}
}
|
Y ejecutamos (también vale con Ctrl + Alt + L).
Podéis ver que se nos aparece una ventana con el resultado de la prueba….
Ha ido bien
Fuera del entorno, solo tenéis que tener precaución con el classpath de los
jar.
Uso de autentificación básica
Podemos, de un modo trivial, también probar páginas protegidas por
autentificación básica.
Este es un ejemplo del ultimo script que he creado para mandaros las
notificaciones de nuevos tutoriales….. (el sistema se justifica por la
existencia de filtros anti-span que cada día me hacen más difícil mandar correos
…… (por eso, si no os llegan algunas veces, que sepáis que no es culpa
mía)).
import net.sourceforge.jwebunit.*;
public class testbasico extends WebTestCase {
public testbasico(String name) {
super(name);
}
public void setUp() {
getTestContext().setBaseUrl("https://adictosaltrabajo.com");
}
public void testEnviarNotificaciones() {
getTestContext().setAuthorization("adictos","zonaprivada123");
beginAt("/mensajes");
this.clickLinkWithText("Enviar novedades a usuario");
this.dumpResponse(System.out);
}
}
|
Conclusiones
Tenemos que ser consciente de que el esfuerzo (y por lo tanto coste) mayor de
un sistema está en su mantenimiento. Las pruebas de regresión implican un coste
impresionante (en tiempo y recursos) que está perdido si no tenemos capacidad de
reutilizarlo. Si no las realizamos, el coste a la larga es mayor (retrasos,
perdida de imagen, repetición de entregas, cambios de planificación, periodos de
crisis, etc.. ).
Existen muchas opciones para realizar estas pruebas de un modo automatizado.
Hay multitud de productos comerciales de distinto espectro
(como eTest de Empirix que os mostramos en un tutorial) y han prosperado
también muchas librerías que, de un modo relativamente sencillo, podemos
utilizar para
realizar estos procesos.
La gracia del tema está en:
- Tener buen criterio para
saber cuando usar unas técnicas u otras (que no es cosa fácil). - Introducir las técnicas y herramientas de un modo no agresivo en la
dinámica diaria de trabajo. - No olvidar la disciplina y calidad en los momentos de crisis (ser maduros
a la hora de desarrollar software).
Si no tenéis metodología de trabajo, tal vez me podáis contratar para que os
ayude (en Madrid) a crearla o consolidarla de un modo gradual (como ya he echo
para importantes empresas a través de cursos de formación).
