TDD con GeneXus, es posible?

Test-Driven Development (TDD), viene ganando adeptos entre diferentes grupos de desarrollo.

Es importante hacer notar, que es una metodologia de diseño de software, mas que de testeo. Si se cumplen todos los pasos, también se favorece la prueba funcional del sistema cuando el mismo esta finalizado.
Hay un conjunto de programas de test (pruebas), que en realidad son una especificación ejecutable del funcionamiento del sistema

TDD tiene las siguientes reglas o pasos a seguir para lograr los resultados.
1) Agregar una prueba
2) Ejecutar las pruebas y ver que solo uno falla
3) Escribir codigo que permita corregir la prueba que falla.
4) Ejecutar las pruebas automatizadas y ver que todo funciona bien.
5) Restructurar el codigo, para que quede todo lindo.
6) Repetir el ciclo.

Varias veces me he preguntado, es adaptable ésta metodologia de desarrollo a un ambiente de desarrollo con GeneXus?.

Voy a tratar de dar mi punto de vista para cada punto.

1) Agregar una prueba.
Una prueba, es un programa especializado en probar que otro programa o un conjunto de programas tienen un determinado resultado conocido, cuando se lo ejecuta en condiciones conocidas de antemano. En el caso de GeneXus estos podrian ser un procedimiento que ejecute otro objeto, le pase determinados parámetros, con la base de datos en un estado conocido y pueda ver que la salida del programa es la correcta (tanto en la base de datos, como los parametros de salida).
Si bien esto es posible, seria muy bueno tener alguna herramienta con funcionalidades similares a xUnit, pero trabajando al nivel de abstracción que lo hace Genexus. Desde hace algunos años está en la vuelta la idea de hacer un GXunit, pero nadie se ha animado o no hemos tenido tiempo de incarle el diente.

Segun el estado actual de GeneXus, las dificultades serian las que vienen por el lado de no poder tener mock objects y también el no poder tener objetos de test diferenciados en la base de conocimiento.

2) Ejecutar las pruebas y ver que solo una falla.
Este paso seria fácil de hacer automatizar, si tenemos bien resuelto el paso 1)

3) Escribir codigo que permita corregir la prueba que falla.
En este punto, la metodologia hace incapie en escribir el codigo mas sencillo que permita la superacion de las pruebas. Creo que en este punto GeneXus esta maravillosamente situado.

4) Ejecutar las pruebas automatizadas y ver que todo funciona bien.
Lo mismo que el punto 2). Habria que contar con un Framework que ayude a ejecutar las pruebas y a ver cuales son las que fallan con un semaforo rojo/amarillo/verde.

5) Restructurar el codigo, para que quede todo "lindo".(Refactoring)
Creo que el cambiar la estructura del codigo y de las tablas de datos para cumplir con los requerimientos, es un area en la que GeneXus se destaca. Es facil renombrar/mover atributos de tablas y el codigo se regenera en forma casi automática. Tambien es facil hacer cambios en el codigo y en propiedades.

6) Repetir el ciclo.

Dificultades
Por lo dicho anteriormente, las dificultades que se tienen para el uso de TDD con GeneXus, serian:

a) No hay objetos especializados para pruebas.
Los mismos no deberian poder instalarse. Deberian tener alguna caracteristica especial para reportar si fallaron o funcionaron bien.
Se podrian llegar a necesitar sentencias del tipo Assert o Try/Catch, para mejorar el manejo de errores ante situaciones no esperadas.
Ademas estos objetos deberian tener un manejo diferente en el ciclo de Reorganizacion/Build all, porque seria bueno que al hacer una reorganización de la base de datos, y al hacer el build all, dichos programas NO SE REGENEREN en esta etapa, de forma de poder corren las pruebas anteriores, con la nueva version de los programas y la base de datos. Saber cuales progamas de prueba fallan, es bueno para saber que cambió en el comportamiento de mi aplicación.
Deberia existir un "Build Test Programs" que se correria en forma posterior a saber que pruebas fallaron y adaptaria las pruebas a la nueva estructura de la base de datos.

Deberian ser distribuibles/consolidables con los objetos que prueban. Aca puede haber algunas diferencias, pues puede no ser lo mismo las pruebas de dos Kb separadas que la suma de dichas pruebas.

b) La prueba utilizando base de datos puede ser muy lenta.
Si para cada cosa que voy a programar tengo que hacer una prueba y ejecutar la bateria de pruebas, estas deberian tener un tiempo de ejecucion rapido, para poder hacer el ciclo veloz.
Esto implicaría poder sustituir los accesos de la base de datos, por objetos en memoria que hagan lo mismo que dichos objetos.
Ademas no es facil hacer pruebas que utilicen la base de datos, que sean independientes una de otra, pues si un programa modifica la base de datos, habria que restaurar el contenido de toda la base de datos al estado anterior o realizar rollbacks.

c) No es facil testear Interfaz de Usuario.
Este es un problema general para todos los lenguajes. Es un problema dificil y quien logre solucionarlo correctamente, le va a llevar una ventaja enorme a todos los demas lenguajes.

Ventajas
Por otro lado, GeneXus tiene una cantidad de ventajas con las pruebas.
i) Podria generar parte de las pruebas en forma automática.
ii) Podria sustituir la base de datos por mock objects en forma "bastante facil".
iii) Podria hacerse programas que capturen el funcionamiento de un programa y vea que la proxima ejecucion sea "igual" con las salidas del mismo.

Conclusiones
Por lo dicho antes y por experiencia personal, creo que hoy en dia es difícil adoptar TDD con GeneXus en forma estricta. Tambien es cierto que no estamos demasiado lejos para conseguirlo y con la versión Rocha, vamos a poder aproximarnos aún mas.

Sé que estoy soñando en blog alta, pero si lograramos tener pruebas asociadas e integradas en nuestras aplicaciones GeneXus, seriamos Gardel con guitarra eléctrica.



Links interesantes:
TDD en español
TDD en amazon
muchos mas que me da pereza agregar..