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
() 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 etcétera.
- 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)
Ah
ora creamos nuestro caso de prueba base (por el
mecanismo de herencia)
import net.sourceforge.jwebunit.*; public class testbasico extends public testbasico(String name) super(name); } public void setUp() { getTestContext().setBaseUrl("http://www.adictosaltrabajo.com"); } public void testHomeAdictos() beginAt("/"); this.assertTextPresent("El arquitecto 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 public testbasico(String name) super(name); } public void setUp() { getTestContext().setBaseUrl("http://www.adictosaltrabajo.com"); } public void testEnviarNotificaciones() getTestContext().setAuthorization("adictos","zonaprivada123"); beginAt("/mensajes"); this.clickLinkWithText("Enviar novedades a 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).
Roberto Canales Mora
www.adictosaltrabajo.com