TDD y GeneXus

TDD (Test Driven Development) es un proceso de desarrollo que se basa en repetir pasos muy cortitos y sencillos, traduciendo los nuevos requerimientos en casos de pruebas y luego modificar el código de la aplicación para que cumpla con esos casos de pruebas (y por lo tanto con los nuevos requerimientos). 
Luego que tenemos el código que pasa todas las pruebas, se realiza el refactoring para evitar codigo repetido u optimizar lo que sea necesario, pero manteniendo todas los casos de prueba. 

El ciclo de ejecutar todas las pruebas de la KB, debería ser rapido para poder ser productivo, pues esto hay que hacer muchisimas veces en el dia.


Con GeneXus 16 se incorpora el objetos Unit Test y una forma fácil de poder ejecutar todos las pruebas de una KB, con lo cual se habilita el desarrollo basado en Test.  

Ventajas

El usar pequeños pasos en el desarrollo, lleva a que es mas  fácil detectar los errores introducidos en la programación que con otros procesos de desarrollo. 
También es siempre bastante fácil volver a una versión que funcione bien, cuando me equivoque en un cambio que realicé. 

La principal ventaja de este metodo, es que al tener que programar primero la prueba y  luego la funcionalidad, el código queda por definición testeable. 

Ademas, generalmente queda mejor estructurado y organizado. Por mi experiencia ademas se hace mas fácil tener código mas corto. 
Por ejemplo, si tengo un objeto webpanel, es mucho mas probable que las funcionalidad queden en procedure y no lo hagan en los eventos, con lo cual queda mas facil de probar. 

Desventajas

Los objetos con interfaz de usuario, son difíciles de probar o de incorporar a este proceso. Pueden dejarse para testar en otro ciclo. 

Es difícil probar objetos que dependan de otros objetos (por ejemplo UC, o servicios externos). Esto es lento y ademas poco confiable. 

Es difícil hacer pruebas de código, cuando se usan base de datos. 
Los datos deben ser conocidos y el estado de la base de datos debe ser conocido antes de hacer las pruebas. Esto es difícil de hacer con una base de datos, y es mas difícil aun, cuando se debe replicar para todos los desarrolladores de un grupo. 

En la misma base de datos donde el desarrollador esta probando, se deben ejecutar las pruebas que usan dicha base de datos y tiene que dar resultados conocidos y se enlentece el ciclo de pruebas. 


Posibles mejoras. 

Seria bueno especificar a GeneXus una base de pruebas y otra base de datos para desarrollar. 
Lo que creo que es que la base de pruebas podría definirse en memoria, de forma de lograr que las pruebas sean rápidas y que también sea posible re-crearla en forma mas o menos facil. 
Esto podría resolverse hoy, teniendo diferentes Environment, uno para desarrollo y otro para test, pero tiene el inconveniente que se duplica el tiempo de especificación y generación, haciendo que el ciclo de desarrollo pierda productividad. 

Lo ideal seria poder tener simultáneamente la base de datos de test y la base de datos donde programo en un mismo environment y que ambas se reorganicen en forma sincronizada.  Cuando corro pruebas, lo hago con una base y cuando ejecuto normal, lo hago con la otra base de datos. 

Creo que el TDD es el mejor proceso que tenemos disponible hoy en dia para mejorar la calidad del código y aumentar la productividad de grupos numerosos. 



Comentarios

Entradas más populares de este blog

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Aplicación monolítica o distribuida?

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.