Desarrollando desde la trinchera

Michael Feathers en su libro  “ Working Effectively with Legacy Code ” define codigo legado (legacy code) como todo  código que no tiene pruebas. Code without tests is a bad code. It doesn’t matter how well written it is; how well structured it is; how well encapsulated it is.Without tests there is no way to tell if our code is getting better or worse. Si nos guiamos por esa definición (que me gusta), puedo decir que la mayoria del codigo que tenemos es Legacy Code y que podemos mejorarlo de muchas formas. Luego de algunos años de práctica, puedo decir que en mi experiencia siempre es mejor tener las pruebas lo  mas cerca del código que sea posible. pues agregan mas valor a mi código.  Por lo tanto, creo que es válida decir que tener Pruebas Unitarias (que prueban solo un objetos procedure o data provider) agrega mas valor que una prueba de integración (que prueban módulos o integración entre módulos) y a su vez agrega mas valor que pruebas de interfaz de usuari...

En el año 2003 (hace ya 14 años!!) empecé este blog con un artículo sobre una herramienta que llamé GXUnit.  Durante varios años hice un esfuerzo junto con otros compañeros de la comunidad de sacar el producto adelante, para que sirviera para lograr usar el testeo unitario dentro del ciclo de desarrollo con GeneXus.  Este año en el #GX27 , nace un interés renovado en GXUnit, pues poco a poco la comunidad GeneXus descubre que la metodología TDD o de Integración Continua (CI) o de Instalación Continua (CD) . Es muy bueno que podamos contar de una vez por todas con lo necesario para poder hacer testeo unitario de calidad y sin demasiado esfuerzo.  Hay varias charlas relativas a DevOps, integración continua y aledaños que recomiendo fervientemente.  Fundamentalmente Lali Aguiar , y Abstracta están haciendo un excelente trabajo para mantener y mejorar la herramienta.  Una de las cosas que le esta faltan al GXUnit para lograr ser realmente un te...

Aqui dejo las diapositivas (que antiguo que suena!!) de la charla que dimos, junto con Alejandro y Uruguay de GXUnit. La charla la dimos gracias al empuje de ellos dos, pues este año estaba medio desmotivado para dar charlas sobre testing.  Mi visión es que el año que viene tendremos alguna herramienta de testeo unitario adaptado a Genexus y sueño con poder exponer las mejoras de productividad al usar XP adaptado a GeneXus. Nuestra Experiencia Con El Proyecto Gxunit Vf View SlideShare presentation or Upload your own. Mas informacion sobre la charla, aqui

Subi a GXOpen , los proyectos GXUnit del Grupo I y Grupo II de Facultad de Ingenieria de la Universidad de la Republica. Son el resultado del trabajo de algunos meses de estudiantes de la carrera de ingeniero de sistemas en computación, del cual participé como tutor (o cliente) junto con Alejandro Araujo y Uruguay Larreborges. Para hacerlos funcionar, hay que bajarse el proyecto, leer la documentacion y hacerle CAMBIOS, para adaptarse a los cambios que surgieron desde diciembre a la fecha. Hay algunos namespaces que cambiaron y tambien se agregaron unos controles a las GeneXus extensions. A pesar de no ser un desarrolo mio, lo subo para que quede disponible por si alguien quiere seguir la tarea. Los links son: Grupo I Download del Proyecto Video de uso de la extension Grupo II Download del Proyecto Video de uso de la extension UPDATE: En menos de 2 horas, se consumió todo el ancho de banda que brinda (1GB) screencast.com, para todo un mes, para ver los videos. Si alguien esta interesad...

Hoy (26/11/2007) a las 18:00 y a las 19:30 horas en el Salon Rojo de Facultad de Ingeniería ( UdeLaR ) se estarán haciendo las presentaciones finales de los dos proyectos de GXUnit . Son dos grupos, que realizaron extensiones de GeneXus Rocha y dos implementaciones diferentes (unos agregando partes a los objetos y otros creando objetos nuevos) para la realización de pruebas unitarias en objetos (por ahora solo procedimientos) de una KB Genexus. Aún falta trabajo para que sea un producto terminado y usable, pero es un punto de partida excelente para continuar en el futuro. Quedé contento con el resultado de dichos trabajos. En los próximos días deberían subir los proyectos a GXOpen. UPDATE: Ambos grupos aprobaron el curso y la presentación con felicitaciones del tribunal examinador. Ahora hay plazo hasta fin de Febrero, para evaluar el producto, donde podremos probarlo un poco mas. Por mis pruebas, ya cumple con lo que se habia planteado en el alcance primario. Uno de los grupos implem...

En la primer entrada de este blog fue dedicada a GxUnit . La idea que planteaba allí, era la de tenar una herramienta con la cual poder hacer pruebas unitarios en GeneXus. Cerca de 4 años después, estamos mucho mas cerca. Hace un tiempo propusimos (junto con Alejandro Araujo y Uruguay Larre Borges) a la Facultada de Ingeniería un proyecto para implementar esta herramienta y ya hay dos grupos que están trabajando en ella. Es un proyecto corto y la idea es que puedan lograr un prototipo mostrable, que pueda probar procedimientos y a lo mejor bussines components. Es gente joven de un excelente nivel que se incorpora a la comunidad Genexus de la mejor forma posible que es la de programar herramientas para ayudar al desarrollo con GeneXus. Creo que valió la pena la espera.

En Google Base Data API vs. Astoria: Two Approaches to SQL-like Queries in a RESTful Protocol, Dare Obasanjo hace una comparación, entre Google Base Data y Astoria. Me resultó interesante la lectura y algo que vamos a tener que acostumbrarnos a usar para hacer mashups y posiblemente otras cosas. via: www.infoq.com AVISO para EL LECTOR DESPREVENIDO: De aquí para abajo, leer SOLO si tiene tiempo para perder, no va a sacar nada en limpio. Mi interés por este tipo de cosas, viene por el lado de la implementación de GXunit. Lo que estoy buscando alguna forma de recuperar resultados de una base de datos, pero desde un alto nivel. Explicando un poco mejor. Una de las ideas de implementación de GXUnit, consiste en tener algunos objetos "Casos de prueba", que tenga la posibilidad de testear procedures y bussines component (en una primera etapa). Pongamos un ejemplo: Si tengo un procedimiento ATestear(in: &Var1, out: Var2); tendria "algo", que me permita especificar para...

Test-Driven Developmen t (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 prog...

En Techniques for testing Data Access Code : Roy Osherove publicó los slides y el código que utiliza para las demo de como testear el código de acceso a datos. Plantea algunas soluciones al problema del testeo unitario con bases de datos, como es el tema de los rollback para dejar todo como estaba al empezar, el tema de las columnas con Autonumber, etc. Está bueno para sacar ejemplos y adaptarlos a la realidad de GeneXus y ver si de una vez por todas se puede tener un porting de un xUnit en GX. Aunque no hay audio de la canción del final, la letra está buena.

Ayer se realizó la charla de Alejandro Araujo sobre GXFit . La presentación de su tesis de maestria estuvo buena, vimos una breve reseña de FIT , una demo Fitnesse y definió el alcance de la tesis. También estuvo lindo el intercambio de ideas posterior sobre como seria la mejor forma de adaptar el uso de testeos unitarios a una herramienta como GeneXus . Es un divertido caso de diferencias de nivel de abstracción entre el nivel de los testeos unitarios y un nivel mas elevado de Genexus. Andrés Aguiar, hizo su planteo (ya expresado en su blog ) en el que no tiene mucho sentido que una herramienta que genera código a partir de una especificación formal como es Genexus, también necesite otra especificación formal (los casos de pruebas programados) para probar que todo funciona bien. También se conversó sobre la posibilidad que fuera el propio Genexus el que generara los programas necesarios para probar los programas generados. A mi esta última opción me gusta mucho, para ser usada de l...

Alejandro Araujo estará presentando este Martes 6/3 a las 19 horas, en la Facultad de Ingeniería su trabajo sobre el GXFit, que es una adaptacion de FIT al mundo GeneXus . La idea basica (y simplificada) es poder crear tablas que contengan los datos de las pruebas a realizar (esta etapa podria realizarla un usuario final de la aplicacion) y que dichas pruebas puedan ejecutarse en forma repetitiva para asegurarse que todo sigue funcionando correctamente luego de realizar cambios. Creo que estas iniciativas y lo que se pueda hacer con el GXUnit y la integración que se logre con la próxima version de GeneXus Rocha, pueden lograr darle un salto en la calidad y confiabilidad de las aplicación que se realicen con Genexus.

En en XIV Encuentro Internacional de Usuarios GeneXus hicimos una presentacion enfocada en el Software Testing. La presentacion que habla sobre el testeo unitario, puede encontrarse aqui

Testeos Unitarios con GeneXus. La posibilidad de definir testeos unitarios con GeneXus es posible, pero para lograrlo seria bueno contar con algunas funcionalidades basicas que hicieran esto mas facil. Por ejemplo, seria bueno poder marcar algunos objetos como que son de testeos, o sea que no forman parte de la aplicaicon a instalar. De esta forma, cada vez que se defina uno objeto, se podrian tambien solicitar un conjunto de procedimientos (que podrian tener una interfaz ya conocida) que va a ser utilizado para hacer la prueba unitaria del mismo. Esto facilitaria la confeccion de testos unitarios y podriamos generar programas para que testearan cada uno de los procedimientos que posee una base de conocimiento. Voy a ver si puedo realizar un pequeño ejemplo y subirlo a GxOpen como "prueba de concepto"

Estoy en el proceso de crear un Framework de Pruebas para programas creados con GeneXus , que podriams llamar GXUnit. En el mismo se podran establecer programas de testeo de clases basicas hechas con Genexus. Esta primera version tendra algunas limitaciones como que solamente se podran hacer pruebas unitarias de procedimientos. Despues haremos algo para probar webpanels y como tercera etapa se puede seguir probando transacciones y workpanels.