Idea para Extension GeneXus para copiar datos para pruebas.
En estos días, estoy en un proyecto que esta migrando un conjunto grande de KBs desde SQL server 2000 a SQL Server 2008. **
Una de las cosas que tuve que hacer (muchas veces!), es poder generarme un conjunto de datos razonables para poder probar, tareas bastante habitual entre los que tienen que testear.
Tenía una base de datos en SQL Server 2000 con muchos GB de datos y debía generarme bases de datos mas chicas para poder usarlas en mi notebook para hacer pruebas en SQL Server 2008.
Estaría bueno tener una extensión que ayude a dicha tarea.
Formalizando el problema:
Tenemos una KB, un objeto main a testear y dos bases de datos (una de producción con datos y otra usada para testear).
Generar una base de datos de pruebas, que tenga todos los datos que necesita el programa a testear para que ejecute en forma correcta.
El programa, debería ver todos los objetos no main, alzanzables desde el objeto a testear y armar la lista de tablas utilizadas y sus operaciones (select, update, delete).
Se debería mostrar la lista de tablas a pasar de una base a otras y poder incluir alguna condición para aquellas tablas que tengan muchos registros o no se quieran pasar completas.
Se puede tener alguna consideración, por ejemplo la de no pasar las tablas que solo se hacen insert y el manejo de los nulos y de la integridad referencial (que no es trivial).
Una vez que se muestra la lista, me gustaría tener dos opciones:
- Generar un script con las sentencias insert para agregar los datos (borrando previamente)
- Preguntar la fuente y destino y hacer la copia de los datos
Creo que podría ser muy útil, para cuando estamos migrando de un DBMS a otro, o cuando tenemos problemas que dependen de datos y son difícil de reproducir en el ambiente de desarrollo.
(1) ** Mas adelante contaré como fue ésta migración.
(2) Mas ideas para extensiones a desarrollar en Genexus X:
(3) Hay varias herramientas que hacen copia de datos de una base de datos a otra y son las que uso ahora para copiar datos, pero son todas propietarias de cada una de las bases de datos y ademas es muy determinar cuales son todas las tablas utilizadas por un conjunto de objetos GeneXus.
Realmente es un tema muy complejo.
ResponderBorrarComento como experiencia (Un caso de éxito) que en donde trabajo hemos realizado pruebas de cambios de DBMS en donde no solo corroboramos el funcionamiento de la aplicación, sino que tenemos las herramientas como para corroborar el correcto funcionamiento de la arquitectura completa (comparando contra otras pruebas realizadas anteriormente).
El trabajo fue realizado en conjunto con la gente del Centro de Ensayo de Software (CES - http://www.ces.com.uy/).
Puntualmente tenemos los script's de casos de prueba, los datos de prueba y los fuentes "congeladas".
Esto nos permite migrar los datos al dbms destino, regenerar la aplicación al DBMS destino y correr los script's para ver el resultado.
Las pruebas son un conjunto de casos de pruebas representativos.
Estos mismos ponen a prueba tanto la aplicación, como la arquitectura montada y al propio DBMS.
Tenemos herramientas de estadísticas que en conjunto con las herramientas utilizadas por el CES nos permiten tener una visión de que cosas nos podemos encontrar en la migración.
Realmente este método nos ayuda mucho a detectar variantes en el comportamiento de las aplicaciones bajo entornos diferentes.
Sin embargo el tema "selección de datos" no ha sido realizado de forma automática, uno de nuestros temas pendientes a resolver.
Tengo entendido que la gente de GXTest (http://www.abstracta.com.uy) permite antes de ejecutar las pruebas en su server ejecutar programas para preparar los datos para los casos de pruebas.
Creo que la gente de CES/GXTest podría dar un poco de info de experiencias y que herramientas han utilizado.
Tenemos tambien a la gente de GXUnit que me imagino que se deben de haber cruzado tambíen con estos temas.
Estaría excelente si el día de mañana existe una herramienta que "tome" una foto de los datos necesarios y los almacene de tal forma que pueda migrarse de forma independiente de DBMS para luego impactarlo contra el que se necesite.
Algo como un SQLCOPY "avanzado" que permita guardar los datos del transfer de forma independiente del DBMS para luego permitir copiar esos mismos contra un DBMS Target sin problemas.
Esa herramienta y sus "archivos" serían transferidos de forma previa a la ejecución de las pruebas y serían parte de la versión del caso de prueba.
Creo que con esto tanto GXUnit, CES, GXTest o cualquiera que implemente pruebas se vería beneficiado.
Lo que menciona Marcos en su blog realmente es cierto, es un proceso muy engorroso y en su momento nos comentó su experiencia con pruebas de regresión.
http://blog.marcoscrispino.com/2009/05/testeos-de-regresion-de-aplicaciones.html
Conozco de algunas herramientas que hacen un poco de esto (algunas adaptadas para ser usadas con GX pero no para todos los DBMS).
Estaría bueno que existiera una solución "formal/final" para GX que cumpliera contra todos los DBMS y que además tenga la inteligencia que menciona Enrique como para permitir una transferencia de "solo los datos necesarios".
¿Alguien conoce si existe alguna solución similar en el mercado para GeneXus? (Comercial o no).
Enrique, me quedé enganchado con esa de "Más adelante contaré como fue ésta migración", quedo a la espera de que nos cuentes tu experiencia.
Arriba y Éxitos!!
Felicitaciones por mantener este blog siempre actualizando con información e ideas muy interesantes.
Enrique,
ResponderBorrarIntentando analizando el problema que planteas se me ocurre una pequeña "optimización".
Según lo que entendí el "Input" de la extension sería:
.- conjunto de casos de prueba
.- BD Original (BD A)
.- BD Nueva (BD N)
.- La KB que es la misma en las dos instalaciones
Estos casos de prueba tienen la propiedad de correr de manera correcta con el DBMS A en la BD A y lo que se quiere es ver si corren de manera correcta con el DBMS B.
Hasta ahí vamos bien no?
Lo primero que debería hacer la extension es determinar que objetos GX se utilizan en las pruebas.
Supongamos que se utiliza el conjunto G de objetos GeneXus en dichas pruebas.
Si se quiere analizar todas las posibles tablas que estos objetos pueden llegar a necesitar, me parece que se llegaría a un conjunto de tablas "demasiado" grande comparado con lo que realmente se va a usar.
Por eso a lo mejor se puede hacer algo más eficiente. Lo que se podría hacer es EJECUTAR el conjunto de casos de prueba y registrar el acceso a la BD, o sea fijarse realmente que sentencias se utilizan.
Capaz que ya lo habías pensado así, pero me pareció que vos no lo estabas planteando al análisis de las sentencias en tiempo de ejecución sino de manera estático no?
Saludos
Matías
David:
ResponderBorrarEl motivo del post, es el de generar los datos de prueba, que en tu caso ya lo tenes resuelto.
El caso de un problema que se da en produccion y no en el ambiente de testeo puede verse beneficiado, con lo sugerido.
Lo que comenta Marcos en su blog (que leo siempre) es la automatizacion de la tarea de test de regresion. Mi idea aca es algo previo.
Marcos y Andres habían hecho una herramienta hace un tiempo que sirve para copiar datos de una base a otra y permiten especificar condiciones y demas. Lo que le estaria faltando, seria la parte de seleccionar que tablas habria que copiar, pues si la cantidad de tablas es muy grandes, puede ser dificil determinar todas las que se necesiten.
MelliMatias:
ResponderBorrarLa optimización que estas sugiriendo, esta buena. Yo lo había evaluado en algún momento y es bastante complejo sacar desde las sentencias ejecutadas cuales son los datos que hay que copiar.
Si se tiene un join complejo, de varias tablas y con condiciones , hay que establecer cuales son las condiciones que corresponden a cada una de las tablas. No es algo que no se pueda hacer, pero agrega una complejidad interesante.
Me conformo con tener una copia de la tabla o generar el script con los inserts y dejar para una segunda etapa tu optimizacion.
Hola
ResponderBorrarGran idea Enrique, si estuviera implementada hoy mismo la estaria usando.
Yo pienso que una vez decidido cuales tablas migrar se debería asegurar la integridad de los datos. Una forma facil es migrar todos los datos de cada tabla pero si se llega a la situacion de pensar en una solucion como esta seguramente esporque estamos ante tablas con toneladas de registros y no hay otra que migrar un subconjunto. Entonces, ahí habría que asegurar que ese recorte no afecte a la consistencia general del paquete de datos migrados.
Aquí si, desde gx esto si es posible con un poco de trabajo.
Saludos!!
Que buena esa herramienta de Marcos y Andres!!.
ResponderBorrarEntonces tienen la mitad del camino ya transcurrido ;).
Faltaría incorporar entonces información para acotar el problema.
¿La idea es copiar solo tablas o de alguna forma identificar la dependencia entre datos?
Ahora que tu lo mencionas, me imagino algo como "Copiar esta lista de Personas", con lo que Personas están asociadas a Domicilios, Teléfonos, y cosas similares, a partir de las dependencias de cada valor de concepto regenerar toda la dependencia y lograr un conjunto atómico y completo para las pruebas, sin tener que copiar absolutamente todo.
Interesante.. interesante.
Algo que he estado pensando adyacente a este tema es que para cada TRN se pueda asociar un DataProvider con datos de prueba.
ResponderBorrarEn principio estos DP los puede cargar el desarrollador/tester, pero tambien se podria generar mas o menos al azar o a partir de una fuente externa (Milano hizo algo para hacerlo con FreeBase).
Nicolas Jodal
Para que esto sea algo practico todavia quedan muchas cosas por resolver, por ejemplo:
* La integridad referencial. Por ejemplo si estoy cargando Facturas, lo que quiero es que hagan referencia a Clientes que fueron cargados en el DP de Clientes.
* Proceso de carga automatico. No tener que programar un proc que lea el DP y haga un Save.
* UI. Una UI que permita visualizar todo el proceso.
Se que no es exactamente lo mismo que estaba necesitando Enrique, pero quizas aporte algo a la solucion final.
Ya que se presta para tirar ideas relacionadas con el post tiro otra idea que en realidad no es mía sino que me la comentaron hace un par de años unos amigos.
ResponderBorrarSi tenemos una herramienta que es capaz de capturar todas las sentencias que se generan con un caso de prueba y luego es capaz de darse cuenta que datos son necesarios para el caso de prueba, tal vez sea factible hacer que esa herramienta "simule" un DBMS con el fin de debaguear la aplicación.
O sea lo ideal sería que el cliente al tener un problema, pueda "grabar" el caso de prueba (acciones y datos que utiliza en la aplicación) y además grabar las sentencias que se intercambian con el DBMS.
De ese modo luego si se manda eso a al Software Factory, se podría ejecutar el caso de prueba como si se estuviese en el cliente debagueando los problemas que podamos tener en la lógica de nuestro sistema.
El foco de esto entonces no sería probar un nuevo DBMS como era la idea de Enrique sino que sería reproducir los problemas que se tienen en un determinado ambiente sin tener que migrar datos.
Saludos!
Lo bueno de estos intercambios de ideas que se producen en los blogs, es que se mezclan temas interesantes.
ResponderBorrarGeneración de datos para pruebas.
Nicolás y Alejandro Panizza (en twitter) hablan de generar datos a partir de transacciones o tablas. Es un tema sumamente util, para cuando estamos en las primeras etapas de desarrollo.
Copia de datos
Mi idea original, era la de poder copiar desde una base de producción un conjunto de datos para un ambiente de desarrollo para permitir la ejecucion similar, para reproduccion de errores.
Registro y deteccion de diferencias
Poder ver la ejecucion y la diferencia entre una ejecucion y otra, sin necesidad de base de datos, muy util para solucionar problemas.
Ademas, se nombraron los problemas de la integridad referencial, que es un lindo problema para resolver.
En algún momento había pensado un algoritmo para saber cuales eran todas las tablas necesarias a copiar y en que orden se debían copiar las mismas.