Pruebas Web con JWebUnit

0
16438

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)

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)).

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).

Sobre el
Autor ..

Dejar respuesta

Please enter your comment!
Please enter your name here