Una cuestión clave en todo contexto de continuous delivery son las pruebas automatizadas. De poco sirve pasar «rápido» entre ambientes, si no podemos garantizar cierta calidad de lo que estamos poniendo en cada ambiente.

Cuando uno construye aplicaciones desde cero, es relativamente fácil generar pruebas automatizadas. El uso de técnicas como BDD y TDD junto con algunos patrones de diseño permiten generar aplicaciones testeables y con alto nivel de cobertura.

Pero no siempre trabajamos sobre aplicaciones nuevas. En ocasiones nos toca trabajar con aplicaciones ya existentes, que muchas veces no cuentan con pruebas y que han sido desarrolladas sin tener en cuenta la testeabilidad. En los contextos ágiles a este tipo de aplicaciones se les suele llamar aplicaciones legacy.

Por suerte son pocos los proyectos, en los que trabajando como programador, he tenido aplicaciones legacy. Sin embargo, trabajando como consultor, me he cruzado bastante a menudo con clientes llenos de este tipo.

Mi estrategia para trabajar con aplicaciones legacy es comenzar haciendo algunas pruebas funcionales que cubran los principales flujos de la aplicación. Y luego a gradualmente comenzar a modificar la aplicación haciendola testeable y agregando distintos tipos de tests según sea posible.

Una combinación de herramientas que me ha resultado interesante para hacer pruebas funcionales es SeleniumIDE + TestNG.

Selenium IDE es una herramienta de automatización de pruebas del tipo Record & Play que funciona integrada con el explorador FireFox y permite que uno vaya recorriendo la aplicación y poniendo aserciones en determinados puntos. Luego la misma herramienta permite reproducir la prueba grabada. Si bien a primera vista la estrategia puede parecer muy interesante, la realidad es que no es tan simple. De hecho este tipo de herramientas de automatización de pruebas ha tenido varias críticas (algunas de las cuales comparto), por diversos motivos que han sido tratados, entre otros, por George Meszaros.

Por su parte TestNG, es una herramienta al estilo JUnit, pero a diferencia de esta, tiene un foco más amplio que la prueba unitaria y por ello provee algunas funcionalidades muy útiles para hacer pruebas funcionales.

A partir de estas dos herramientas, mi estrategia es:

1. Diseñar la prueba y crear la «cáscara» de la prueba con TestNG
2. Grabar la prueba con Selenium IDE
3. Exportar el script resultante a Java
4. Tomar el código del script Java generado y usarlo para completar la cáscara creada con TestNG
5. Ajustar la configuración del driver de test (pues si bien por default viene FireFox, uno podría querer/necesitar probar con otro browser)
6. Ajustando el código de prueba en TestNG tomando en cuenta la particularidades de la prueba
7. Ejecutar las pruebas con TestNG

Dos cuestiones importantes a considerar para utilizar este enfoque y que son las que abarca el punto 5 son:

1. Es posible que para ejecutar las pruebas sea necesario contar con un estado particular de la aplicación que puede no ser trivial de generar
2. Es muy común que los datos de tests requieran cierto grado de «dinamismo». Aquí puede resultar muy útil la funcionalidad de TestNG que permite definir sets de datos de prueba.

Bien, esto es todo por el momento.

Como siempre, si tienen alguna consulta/inquietud, no duden en escribirme.