En esta última entrega de mi serie sobre tests de unidad, quiero hablaros brevemente de dos asuntos relacionados con este tema: tests de integración y compilación continua.
En estos artículos os he explicado cómo escribir tests que pongan a prueba los elementos de vuestro software por separado, libres de la influencia de los otros elementos. Sin embargo, estas pruebas no son suficientes: tener varios elementos que funcionan correctamente por separado no significa que vayan a funcionar bien al ponerlos juntos. Por ejemplo, puede ser que uno de nuestros módulos espere fechas en formato día-mes-año y la base de datos las produzca en formato mes-día-año; tal vez nuestro módulo funcione perfectamente al igual que la base de datos, pero cuando intentemos pasar una fecha entre uno y el otro tendremos un problema bastante gordo.
Para evitar esto tenemos que introducir un nuevo tipo de test: los tests de integración. Grosso modo, los tests de integración consisten en “ensamblar” varios módulos, o incluso el programa entero, y comprobar que varias acciones tienen los efectos deseados. Un caso especial de test de integración es el “end-to-end test” (“prueba de un extremo al otro”), que consiste en arrancar todo el programa (configurado para acceder a bases de datos específicas para pruebas), realizar operaciones en el interfaz de usuario utilizando una herramienta de automatización, y comprobar que estas operaciones se reflejan en la base de datos.
Por su naturaleza, los tests de integración se ejecutan más lentamente que los tests de unidad, así que puede llevar mucho tiempo ejecutarlos. Por ese motivo, los programadores normalmente no ejecutan los tests de integración de forma rutinaria, sino que lo hace el servicio de compilación continua.
Un compilador continuo (“continuous build”) es un servicio que “vigila” el sistema de control de versiones y, cuando detecta que alguien ha hecho “commit” de una nueva versión del software, la descarga, la compila y ejecuta todos los tests. Los compiladores continuos suelen estar conectados a varios sistemas de notificación de estado, como email, páginas web, pantallas, o incluso semáforos. Estos sistemas indican el estado de la última versión compilada por el servicio; “rojo” si hubo algún problema al compilar o ejecutar los tests, o “verde” si no hubo ningún problema.
En muchos sitios se utiliza el compilador continuo para asegurar la calidad del software. Por ejemplo, en muchos sitios está prohibido hacer “commit” si el compilador continuo está rojo, a menos que sea para arreglar el fallo. A la hora de escoger una versión para poner en producción, la elección es mucho más fácil: la última versión verde disponible. De hecho, en algunos sitios ponen en producción una nueva versión cada día; esta versión, por supuesto, es la última versión verde disponible.
Y con esto termino mi serie sobre tests de unidad. Espero que os haya inspirado para empezar a escribir y mantener tests de unidad en vuestro software si no lo hacíais antes, y para aprender más sobre el tema si ya lo hacíais. Es posible que en el futuro escriba sobre otros asuntos técnicos; sólo tenéis que escribirme para sugerir temas.