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 WebTestCase { public testbasico(String name) { super(name); } public void setUp() { getTestContext().setBaseUrl("http://www.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("http://www.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).
Roberto Canales Mora
www.adictosaltrabajo.com