Historia y arquitectura de GXUnit
•Télécharger en tant que PPTX, PDF•
0 j'aime•445 vues
GXUnit es un framework de la familia xUnit que da soporte a pruebas unitarias en GeneXus
Recommandé
Contenu connexe
En vedette
Similaire à Historia y arquitectura de GXUnit
Similaire à Historia y arquitectura de GXUnit (20)
Historia y arquitectura de GXUnit
- 1. Juan Pablo Goyení Proyecto de grado Marcos Olivera Facultad de Ingeniería Nicolás Carro UdelaR
- 2. Historia de GXUnit …….
- 3. Herramientas Pruebas unitarias GXUnit xUnit
- 5. Motivación Fuente: Applied Software Measurement, Capers Jones, 1996
- 6. Herramientas Pruebas unitarias xUnit
- 7. Herramientas xUnit Características • Automatización • Embebido en el lenguaje • Ejecución • Velocidad • Visualización
- 8. Herramientas xUnit Estructura de los Casos de Prueba • Setup • Llamada a la unidad • Asserts • Teardown
- 9. Herramientas xUnit Herramientas estudiadas • JUnit • PBUnit • GXUnit PIS • NUnit • Otras…
- 10. Herramientas xUnit Puntos fuertes tomados • Casos de prueba programables • Generación automática de código • Ejecución desde entorno de desarrollo • Suites de prueba • Adaptable a la versión
- 11. Herramientas Pruebas unitarias GXUnit xUnit
- 12. Arquitectura Se busca que sea … • Independiente • Mantenible • Bajo Acoplamiento • Compatible • Extensible
- 13. Arquitectura GXUnit GXUnitUI GXUnitCore GeneXusAPI GeneXus SDK
- 14. Arquitectura GeneXusAPI • Recibe solicitudes de GXUnitCore • Crea: – Procedimientos – Data Providers – Structured Data Types – Carpetas – Transacciones
- 15. Arquitectura GXUnitCore • Núcleo de GXUnit • Recibe solicitudes de GXUnitUI • Define: – AssertStringEquals – AssertNumericEquals – RunnerProcedure
- 16. Arquitectura GXUnitUI • Crear TestCase • Crear Suite • Ejecutar TestCase • Ejecutar Suite • Visualizar Resultados
- 17. GXUnit Unidad en GeneXus • ¿Unidad en GeneXus? • ¿Objetos GeneXus? • ¿Cuáles Objetos?
- 18. GXUnit Objetos GeneXus 1 8 8 31 Transactions Table Procedures Web Panels Data Provider 52
- 19. GXUnit
- 20. GXUnit Test Case
- 22. GXUnit Result
- 23. Demo
- 24. Resultados • Cumplimiento de los objetivos clave • Casos de estudio - PIS 2011 • Consolidación de GXUnit en la comunidad –a – Blog / Site / Consultas • Trabajo a futuro – Generación de datos de prueba – Integración con GXtest – Ejecución batch de pruebas – Smart devices – Generación de reportes
- 25. Agradecimientos • Encargados del Proyecto de Grado – Mónica Wodzislawski (Tutor del proyecto) – Matías Reina (Usuario responsable del proyecto) – Federico Toledo (Usuario responsable alterno) • GeneXus Extensions • Integrantes de los 2 grupos – Luciano Silveira GXunit del Proyecto de – Federico Azzato Ingeniería de Software 2007 • GeneXus Marketplace • Integrantes de los 2 grupos – Martín Olivieri GeneXus del Proyecto de • Gustavo Carriquiry Ingeniería de Software 2011 • Ursula Bartram • Alejandro Araujo • Enrique Almeida
Notes de l'éditeur
- Buenas tardes, soy Nicolás, estamos defendiendo el proyecto de grado junto con mis compañeros Juan Pablo y Marcos.El proyecto se trata de GXUnit, un framework que da soporte a las pruebas unitarias integrado a GeneXus.La idea de la presentación es mostrar el trabajo realizado en el proyecto, indicando el estudio realizado sobre pruebas unitarias y presentar la herramienta construida con una pequeña demo para mostrar su funcionamiento.
- Pero antes de arrancar me gustaría mostrar un poco de la historia del gxunit….La propuesta surge de una idea en el 2003 de crear una herramienta de automatización de pruebas unitarias en GeneXus, en una charla abierta en el encuentro GeneXus de ese añoLuego al año siguiente se formaliza la propuesta en la línea de las herramientas xUnit.En el año 2006 se presenta un documento llamado “Proyecto Colaborativo GeneXus” donde se describen requerimientos para la herramienta y en el año 2007 en el curso proyecto de ingeniería de software de la facultad de ingeniería se construye una primera versión.Esta primera versión pudo ser construida gracias a que la versión 10 de Genexus incluyó el concepto de extensiónUna extensión puede agregarse a genexus desarrollando en .NET una dll que utiliza el Software Development Kit de GeneXus (SDK)En el año 2010 surge como proyecto de grado para construir una nueva versión de la herramienta.Se deja abierta la línea de tiempo al futuro ya que la idea es que GXUnit siga creciendo..El principal objetivo de este proyecto es desarrollar una herramienta que de soporte a pruebasunitarias en GeneXusVolcado a cumplir necesidad de la industria …
- Vamos a mostrarles brevemente algunos de los beneficios de las pruebas unitarias, luego de las herramientas xUnit, y finalmente presentaremos la herramienta xUnit para GeneXus – GXUnit.
- ¿Que son las pruebas unitarias?Las pruebas unitarias verifican, de forma aislada, la funcionalidad de partes o unidades de software que pueden probarse por sí solasDeben poder ejecutarse de forma rápida porque las unidades que se están probando están en constante cambio por lo que deben ejecutarse las pruebas de forma constanteDependiendo de la metodología de desarrollo pueden ser realizadas por los desarrolladores o por equipos de testing.Por ejemplo si se una unametología “agil” como TDD se puede generar primero la prueba y luego el código que hace que se cumpla la prueba…Con las pruebas unitarias se intenta detectar errores en etapas temprana del desarrollo (negociación de requerimiento, diseño, desarrollo de unidades de software)…
- … que es donde generalmente se introducen más errores.Esto puede verse en la siguiente gráfica, la mayoría de los errores se comenten en la etapa de desarrollo (o inclusive antes en el negociación de requerimiento, diseño, etc que falta en la gráfica) y la mayoría se encuentran en etapas más avanzadas (pruebas funcionales y de sistema) donde el costo de arreglar el error es mayor. // todo señalando a la graficaPor lo que las pruebas unitarias son una buena manera de encontrar errores cuando son menos costosos de arreglar.Con un buen conjunto de pruebas unitarias, se puede modificar el código con más seguridad y tranquilidad, porque tenemos el respaldo de las pruebasSirven como documentación para el desarrollador. En muchos sistemas legados se tiene miedo de cambiar el código lo que conlleva a una perdida de agilidad en el mantenimiento del sistema.Y como se ejecutan las pruebas unitarias?Una manera es realizarlas manualmente, sin ningún tipo de automatización, pero nos llevan a repetir código todas las veces, a tener que crear interfaces graficas a medida (en genexus debemos construir un web panel que llame a la unidad), un costo que muchas veces hace que se pierda interés en realizarlas y se termina evitandoPero desde hace tiempo existenherramientas (frameworks) que nos ayudan a realizar pruebas unitarias.
- Estos frameworks son las herramientas xUnit.Son un conjunto de frameworks de pruebas unitarias en distintos lenguajes de programación y plataformas de desarrollo.Dan soporte para probar diferentes elementos o unidades de softwareUno de los más conocidos y más utilizados es JUnit para Java que quizás lo conozcan
- Al diseñar las pruebas en el mismo lenguaje que el sistema que se está verificando permite a los desarrolladores trabajar en el mismo ambiente de desarrollo que ya utilizan y mantenerse en una sola aplicación y trabajando con lo que ya conocen.Generalmente permiten ejecutar las pruebas de forma integrada al ambiente de construcción del software Permite ejecutar de forma veloz, y visualizar los resultados de forma clara (con color rojo si falla o verde si pasa).Al construir un caso de prueba se define cual es el resultado esperado de una unidad de software y luego al ejecutarlo se compara con lo que realmente se obtiene. Al comparador se le llama Assert.
- La estruicturatipica de un caso de prueba en las herramientas xUnit es la siguienteSet up: se construye un contexto para el caso de prueba, se inicializa la base de datos y se inicializan los parámetros de entrada y demás variables necesarias para ejecutar la unidad bajo pruebaLlamada: Se llama a la unidadAsserts: Se compara los resultados obtenidos con los esperados mediante assertsTeardown: se deshace el contexto de la prueba (se deja el ambiente en el mismo estado que estaba antes de ejecutar la prueba)
- Para hacer el proyecto estudiamos varias herramientas para tomar buenas ideas…Junit para Java como ya mencioné es la más utilizada en la industria y una de las que más ha evolucionado por lo que fue muy útil para tomar buenas prácticasProvee anotations en Java para set up (Before), teardown (After) y ejecución de las pruebas (test).PBUnit es una herramienta para PowerBuilder. Esta herramienta fue estudiada para ver como se realizan pruebas unitarias en PowerBuilder por la similitud que tiene a GeneXus en el sentido de ser Generadores de aplicacionesGXUnit PIS. Por supuesto estudiamos la versión anterior de GXUnit, por más que ya no puede ejecutarse por los cambios que ha tenido el SDK de GeneXus nos interesaba ver como resolvieron ciertos problemas con GeneXusNunit para .net fue estudiada capaz como un ejemplo de lo que no se debe hacer. Unos de los puntos más debiles de este framework es que se debe ejecutar como una aplicación aparte lo que obligaba al usuario a salir del ambiente de desarrollo para tener que ejecutar pruebas unitariasSe estudiaron además otras herramientas tanto xUnit como complementarias a los frameworksxUnit como DBUnit para aislar la Base de datos para pruebas unitarias, EasyMock y Jmock para crear mocks de los objetos llamados por la unidad que se está probando..
- A partir del estudio de las distintas herramientas fueron tomados distintos puntos fuertes de las mismas para obtener así características deseables de GXUnitFueron identificadas las siguientes para ser incluidas:-Código programable en testcase: vemos que es muy útil que se pueda programar el código del caso de prueba para poder construir sin restricciones el caso de prueba que se desee. Uno de los puntos debiles de la primera versión de GXUnit (2007) era que no daba total libertad a la hora de crear el testcase.Para crear los casos de prueba se utilizaba una tabla con valores de entrada y resultado esperado, esto ayudaba a la practicidad de la herramienta pero le quitaba potencia-Generación automática de código: Como hacemos para darle potencia pero a su vez no tener que desarrollar desde cero cada caso de prueba? Introducimos Generación automática de código. Esto es, al crear un caso de prueba se genera automáticamente un código por defecto que invoca al objeto a probar, inicializa parámetros de entrada y asserts de los parámetros de salida.-Practicidad en el uso: Esto da practicidad en el uso pero más practicidad aún da el poder ejecuatar las pruebas (todas o un conjunto) mediante el uso de un botón de pruebas. Si se cambia un código y se quiere ver si no se “rompió” una funcionalidad se pueden ejecutar todos los casos de prueba que se vean afectados simplificando parte de las pruebas de regresión.-Integrada en ambiente desarrollo: Un gran punto que ya fue mencionado como importante es la integración al ambiente de desarrollo del programador para no tener que cambiar de aplicación para ejecutar las pruebas.-Suites de prueba: Contar con una manera de organizar los casos de pruebas es primordial una vez que se empiezan a acumular muchos casos de prueba-Independencia de versión: Es deseable que los cambios en el lenguaje para el que está diseñada la herramienta impacten lo menos posible en la misma. O sea acotar los componentes que dependen de la versión.Nos alegra decir que todos estos puntos fuerte fueron incluidos en la solución de GXUnit
- Metiéndonos en GeneXus, es que surge GXUnit, que es un Framework de la familia xUnit para dar soporte a las pruebas unitarias en este ambiente de desarrollo.Ahora los dejo con Marcos que va a hablar de la herramienta construida.12 min aprox.
- Gxunit desde su comienzo fué pensado para seguir creciendo más halla del alcance de este proyecto por lo cual teníamos que definir una arquitectura que cumpliera con este cometido.otro pilar fundamental era independizar la lógica de la herramienta con la comunicación con el sdk de genxus.Para lograr minimizar el impacto tras modificaciones del sdk y lo que hicimos fué encapsular esa comunicación en un módulo independiente de esta manera logramos acotar la dependencia con el sdk.Otro punto fuerte que nos planteamos fué maximizar la utilización de código genexus, esto nos asegura la compatibilidad con los distintos lenguajes que genexus genere o pueda llegar a generar en el futuro. Hoy probamos la herrmeinta generando java rubycsharp y escribiendo la mayor parte del código en GeneXus no fue necesario escribir código específico en esos tres lenguajes.
- Para cumplir con todos estos objetivos decidimos definir una arquitectura en capas, de esta forma logramos desacoplar la lógica de la herramienta con la comunicación con el sdk, definiendo una capa de comunicación GENEXUSAPI y en otra el núcleo de la herramienta Gxunitcore.La experiencia que recogimos de los grupos de pis del año 2007 fué muy importante para tomar esta decisión. La lógica de la herramienta y la comunicacióncon el sdk estaban acopladas lo que dificultó el mantenimiento tras la evolución del SDK y la comprensión del funcionamiento de la herramienta.
- La capa Genexusapi recibe solicitudes de la capa superior gxunitcore y las procesa utilizando las funcionalidades del sdk de genexus. Por ejemplo, para crear un objeto procedimiento no es necesario tener conocimiento del sdk, basta con invocar el método crear procedimientode Genexusapi pasándole por parámetro el source, la regla parm, una lista de variables y una lista de propiedades (por ejemplo si es main, o el protocolo de ejecución).
- La capa Gxunitcore es el núcleo de gxunit, es independiente del sdk de genexus. Por ejemplo, crea la definición de los procedimientos de asserttion, con el código fuente, la regla parm, las variables, las propiedades y delega la creación del mismo a Genexusapi.Principalemnte resuelve las solictudes recibidas de la capa superior Gxunitui.
- El objetivo de gxunitui es mantener la comunicación entre el usuario y la herramienta. recibe ditintos comandos por parte del usuario, como crear test case, crear test suite, ejecutar test case, ejecutar test suite. También muestra los resultados de las ejecuciones de los casos de prueba al usuario.Resumiendo, ya vimos los obejetivos planteados para la definición de la arquitectura, las justificaciones de las decisiones toamdas para la construcción y la definición de la arquitectura misma, una arquitectuar en capas con tres componentes, Genexus Api, Gxunitcore y Gxunitui
- Luego de definir la arquitectura nos planteamos las siguientes interrogantes:A que le vasmos hacer pruebas unitarias?Qué consideramos una unidad en genexus?Lo mas natural sería un objeto ,pero el concepto de objeto en genexus es distinto al de otros lenguajes, genexus maneja distintos tipos de objetos.Ante esta duda lo que hicimos fué analizar distintas kbs de producción y construimos la siguiente gráfica.
- Como pueden ver el objeto procedimiento es el q más aparece en la kbs de producción, además concentra mucha lógica de negocio, por eso lo consideramos el objeto mas importante a la hora de realizar pruebas unitarias.Despues tenemos el objeto web panel que no lo consideramos tan importante porque no concentra lógica de negocio crítica.Además hay otras herramientas como gxtest que dan soporte a pruebas en los web panels.Despues tenemos las tablas que por si solas no tiene sentido probarlas de forma unitaria.Las transacciones como bc si, es un objeto q concentra mucha lógica de negocio.Por ejemplo, quiero saber si se dispara una regla, o el valor de un atributo fórmula.Despues tenemos los data providers, que a pesar de no aparecer demasiado en las kbs de produccion lo incluimos en el alcance porque cada vez se están utilizando más y concentra lógica de negocio crítica.
- Resumiendo, teníamos estos objetos que eran candidatos de probarlos de forma unitaria seleccionamos estos tres para incluirlos en el alcance del proyecto.Luego de finalizar el estado del arte del proyecto presentamos el mismo en el CES a las personas que estuvieron involucradas desde el origen de GXUnit, con el fin de relevar nuevos requerimientos para la herramienta y planteamos la interrogante de a cuáles objetos realizar pruebas unitarias donde también surgieron estos 3, Procedure, Transaction como Business Component y Data Providers.Y ahora que sabemos a q le vamos hacer pruebas unitarias, pasamos a ver como resolverlas en gxunit.Lo que hiciomsfué definir un nuevo tipo de objeto, el objeto test case.Este objeto está basado en un prodcedimientoLo que ganamos con que sea un procedimiento? podemos utilizar la sintaxis para construir pruebas mas ricas, el programador puede hacer foreachs, whiles, inicializar el estado de la base, volver al estado original, el progamador tiene toda la libertad al momento de crear las pruebas. Ademas puedo tener los casos de prueba almacenados en la base de conocimiento, puedo importar y exporta entre distintas kbs
- Cuando creamos una prueba un test case asociado a un procedimiento por ejemplo, gxunit define un código por defecto, te define todas las variables, te inicializa los parámetros de entrada, hace la llamada al objeto bajo prueba y hace el assert correspondiente, dependiendo del parametro de salida, en este caso como es de tipo numeric, hace el assertnumericecuals.Pueden ver tambien que el assert no es nada mas que un objeto procedure. Decidimos hacerlo de esa manera porque si en un futuro se introduce un generador para otro lenguaje, no es necesario re implementar el assert para ese nuevo lenguaje.Hoy en día lo tenemos probado para java csharp y ruby y no necesitamos implementarlo para los tres lenguajes. El hecho de que esté implementado en genexus asegura que va a seguir funcionando para otro lenguaje generado.Además el hecho de que sea un procedimeinto facilita la comprensión para el programador y el Puede definir sus propios asserts.Puede abrir un assert que viene por defecto en la herramienta y lo modifica para implementar su propio assert, para algun tipo de datos que utiliza mucho y le paresca necesario, eso le da mucha flexibilidad.
- Tambien introducimos el concepto de suites de prueba, que nos brinda un suite de pruebas?, nada mas que una forma de poder agrupar los casos de prueba segun un criterio predefinido por el programador, por ejemplo, todos los que prueban al procedimeinto suma, o todos los que prueban a la transacción cliente. Que ganamos con esto? podemos acceder rapidamente a todos los casos de prueba dsiponibles en la base de conocimiento. Mantener un orden entre los casos de prueba. Puedo ejecutarlos como un conjunto. Por ejemplo si hago una modificacion en el objeto suma, busco las pruebas asociadas, las ejecuto, y si no falla ninguna prueba puedo aseverar con mayor certeza que no introduje un error. Tambien podemos ejecutar todas las pruebas definidas en la kb, seleccionando el check box, se seleccionan todos los casos de prueba, hago click en test y rapidamente se ejecutamos todos los casos de prueba definidos en la kb.Esto es fundamental a la hora de hacer pruebas de regresión. Si tengo que hacer una modificación en una unidad crítica del sistema la puedo hacer con mas seguridad porque tengo el respaldo de las pruebas y puedo acceder rapidamente, no es necesario salir del entornode desarrollo para ejecutarlas, está integrado al entorno de desarrollo.
- Para la visualización de estas ejecuciones definimos un nuevo tipo de objeto, el objeto result, como pueden ver es un arbol que contiene toda la información de la ejecución de las pruebas, los casos de prueba que se ejecutaron, el tiempo de ejecución de cada caso de prueba, a que suite o conjunto de suites pertenece y lo mas importante, el resultado de los asserts por ejempo si no hubieron errores tenemos un assert ok en verde sino un assertfail en rojo, expandido con el valor esperado y el valor que se obtuvo de la ejecución.También tenemos un resumen con el total de pruebas ejecutadas y la cantidad que fallaron. Ahora ya vimos un pantallaso de gxunit, vimos que está integrada al entorno de desarrollo, es flexible a la hora de construir las pruebas, o de construir nuevos asserts.Ahora los dejo con juan pablo que les va a mostrar ejemplos prácticos de utilización de la herramienta.
- Como se puede ver la herramienta está Integrado al entorno de GeneXusEsto hace que sea más práctica su la utilización y adaptable a cualquier lenguaje en que GeneXus genere.Nuevo Tipo de objeto “Test Case”Basado en el tipo ProcedureFlexibilidad para implementar casos de pruebas. Generación de código por defecto Define código por defecto según el objeto a probar y sus parámetros de entrada y salida.Almacenar pruebas en la KBImportar y exportar entre distintas KBsConcepto de Suites de prueba, se puede ver que agrupan casos de prueba para ordenarlos y ejecutarlos como un conjunto.Las suites son una caracteristica de las herramientas xUnitSuitesFlexibilidad para agrupar casos de pruebaEjecutar conjunto de casos de pruebaEjecutar todos los casos de prueba definidos en la KBFacilidad para realizar pruebas de regresiónAssertionsProcedimientos GeneXusIndependiente del lenguaje generadoCompatibilidad hacia adelanteFacilidad para agregar nuevos tipo de AssertsAssertNumericEqaulsAssertStringEquals-AssertSDTEqualsNuevo tipo de Objeto “Resultado”Árbol con los datos de la ejecuciónNombre de la pruebaNombre de la/s Suite/s que pertenece Tiempo de ejecuciónResultado de assertions
- Integrar Resultados contrabajo a futuroHablardelmarketplace, blog, siteCaso de Estudio…
- Como se puede ver la herramienta está Integrado al entorno de GeneXusEsto hace que sea más práctica su la utilización y adaptable a cualquier lenguaje en que GeneXus genere.Nuevo Tipo de objeto “Test Case”Basado en el tipo ProcedureFlexibilidad para implementar casos de pruebas. Generación de código por defecto Define código por defecto según el objeto a probar y sus parámetros de entrada y salida.Almacenar pruebas en la KBImportar y exportar entre distintas KBsConcepto de Suites de prueba, se puede ver que agrupan casos de prueba para ordenarlos y ejecutarlos como un conjunto.Las suites son una caracteristica de las herramientas xUnitSuitesFlexibilidad para agrupar casos de pruebaEjecutar conjunto de casos de pruebaEjecutar todos los casos de prueba definidos en la KBFacilidad para realizar pruebas de regresiónAssertionsProcedimientos GeneXusIndependiente del lenguaje generadoCompatibilidad hacia adelanteFacilidad para agregar nuevos tipo de AssertsAssertNumericEqaulsAssertStringEquals-AssertSDTEqualsNuevo tipo de Objeto “Resultado”Árbol con los datos de la ejecuciónNombre de la pruebaNombre de la/s Suite/s que pertenece Tiempo de ejecuciónResultado de assertions