GXunit es la herramienta de pruebas unitarias para el entorno de desarrollo GeneXus. El objetivo, como el de todo framework de unit testing, es el de poder programar pruebas dentro del mismo IDE de desarrollo, en el mismo lenguaje. De esta forma, en GeneXus se podrían crear objetos y procedimientos de prueba dentro de la KB (en el modelo de desarrollo de la herramienta), pudiendo ejecutarlo desde el mismo entorno, de forma ágil y obteniendo resultados rápidos. Justamente lo que se busca con el testing unitario, es poder realizar cambios (agregar funcionalidad, modificar, refactorizar, etc.) y ejecutar verificaciones que en forma inmediata me indiquen si esos cambios introducen algún problema al código.
Nueva versión de GXunit
En el último tiempo, Laura Aguiar se puso a trabajar sobre lo que estaba bastante abandonado, y recientemente publicó sus primeros avances.
- Documentación en la wiki de GeneXus sobre GXunit. Incluye un manual, guía de uso y las indicaciones para ejecutar desde un entorno de Integración Continua.
- Código de GXunit en Github, ya que se sigue tratando como un proyecto opensource.
- Documentación en Github, incluyendo una lista de próximos pasos (que se ven bien interesantes).
Resumen de la documentación
- Cómo comenzar: luego de instalar la extensión, es necesario crear los objetos de GXunit, para lo cual encontrarán un nuevo menú en GeneXus llamado “GXunit”, y ahí deberán seleccionar “Create Objects”. Esto solo se hace una vez en cada proyecto. Se crearán los objetos necesarios para ejecutar pruebas unitarias, y un folder GXUnitSuites, donde se irán creando y guardando los casos de prueba. Leer más aquí.
- Cómo funciona: básicamente uno crea procedimientos que tienen como objetivo el probar una unidad (el concepto de unidad depende de cada uno, pero la idea siempre es mantener las pruebas cortas, simples, rápidas, específicas). Los tests se agrupan en suites de prueba. Estos programas que ejecutan las pruebas se guardan en la KB. Hay una ventana en la que uno puede seleccionar los tests que quiere ejecutar, y en ese momento se regenera el programa llamado GXUnit_LoadTests, de forma tal que sea un programa que invoca a cada uno de los tests seleccionados. No es necesario regenerar este programa, para ejecutar los mismos tests seleccionados simplemente se ejecuta el programa GXUnit_RunTests, el cual puede ser invocado desde nuestra herramienta de integración continua.
- Cómo escribir un test: la documentación muestra un simple ejemplo, de donde pego la siguiente imagen para que se pueda entender cuál es el formato en el que trabaja, donde el test sigue la estructura de inicializar datos, invocar al procedimiento bajo pruebas y luego verificar el resultado esperado:
- Cómo ejecutar los tests desde CCNet (para integración contínua): GXunit genera un archivo XML con los resultados de cada ejecución. Aún se está trabajando para facilitar este proceso (leer aquí y aquí), e incluso para que a futuro se puedan utilizar distintos servidores de integración continua, como por ejemplo Jenkins.
Un poco de historia de GXunit
Ya se han hecho diversos intentos (según este paper, desde el 2003, incluso encontré que el primer post de desarrollando desde la trinchera hablaba que comenzaría a trabajar sobre esta idea). Estos intentos incluye proyectos colaborativos de GeneXus y GXopen, maestrías investigando el tema, proyectos de grado de la Facultad de Ingeniería, donde Enrique Almeida, el CES, incluso nosotros (Abstracta) nos hemos involucrado y hemos dado algún impulso, pero aún no ha sido adoptado por la comunidad.
Hace tres años atrás subimos una versión al Marketplace de GeneXus, donde actualizamos lo que había a la última versión de GeneXus, y esta versión daba la posibilidad de ejecutar las pruebas desde MSBuild, como para poder ejecutarlas desde el entorno de Integración Continua. En su momento habíamos aportado también con esta documentación en nuestra wiki, que la dejo de referencia ya que puede ser útil.
Comentario final
A mí lo que me resulta extraño es que aún no se haya adoptado la práctica de test unitario en un mundo donde todo se mueve hacia el agilismo, y en una comunidad donde se promueve la facilidad del cambio. ¿Cómo puedo cambiar rápido y poner en producción sin ejecutar al menos un conjunto de pruebas unitarias? Esto debería formar parte del proceso básico y estándar de desarrollo, pero hasta el momento no ha sido así. Espero que este nuevo impulso haga que se siga concretando esta idea, dándole cada vez más madurez a las prácticas que se realizan con GeneXus, que tan importante ha sido en el desarrollo del sector informático en Uruguay.
