Presentación del estado del arte Proyecto GxUnit Presentación del estado del arte Facultad de Ingeniería - UdelaR Juan Pablo Goyení Marcos Olivera Nicolás Carro

Agenda Introducción Lenguajes de Cuarta Generación GXUnit Motivación Objetivos Lenguajes de Cuarta Generación Power Builder GeneXus Pruebas Unitarias y Herramientas XUnit JUnit PBUnit GXUnit (versión 2007)

Agenda Objetos GeneXus ¿Qué es una unidad? Características de GXUnit Unidad en Java Unidad en Power Builder Unidad en GeneXus Características de GXUnit Como desarrollar GXUnit Ejemplo de extensión

Introducción GXUnit GXUnit tuvo su origen en el año 2003 En el año 2004 se formalizó la propuesta en la linea de las herramientas xUnit. En el año 2007 se propuso el desarrollo del proyecto en el curso “Proyecto de Ingeniería de Software”. En el año 2010 se propuso el desarrollo del proyecto en el ámbito del curso “Proyecto de Grado”.

Introducción Motivación “Las fallas más notorias en la historia del desarrollo de software fueron todas debidas a defectos en las unidades, defectos que podrían haber sido encontrados con apropiadas pruebas unitarias”.(Boris Beizer) La identificación temprana de errores reduce el esfuerzo de corrección y el costo de los proyectos. En GeneXus las pruebas unitarias requieren mucho tiempo y esfuerzo por parte del desarrollador.

Introducción Objetivos Desarrollar GXUnit contemplando los siguientes requerimientos: Creación y mantenimiento de pruebas unitarias. Ejecución de pruebas. Registro de resultados. Integración con el ambiente GeneXus. Simulación de Objetos GeneXus (Mocks). Simulación de consultas SQL a la Base de Datos.

Lenguajes de Cuarta Generación ¿Qué es un Lenguaje 4GL? Diseñado con un propósito específico. Más cerca del Lenguaje Natural. El desarrollador indica “qué” se debe hacer, no “cómo”. Diseñado para reducir el esfuerzo de desarrollo.

Power Builder Lenguaje 4GL orientado a objetos. Desarrollo de aplicaciones de clase empresarial. Soporta arquitecturas cliente/servidor, distribuidas y web. Las aplicaciones son dirigidas por eventos. Brinda facilidades para el acceso a Bases de Datos, diseño de reportes e interfaz de usuario. Incluye un lenguaje “Power Script” usado para definir el comportamiento de la aplicación ante los eventos.

GeneXus Lenguaje de Cuarta Generación. Orientado a especificar Sistemas de Información. Metodología de desarrollo dirigido por Modelos. Captura e integra las visiones de los usuarios en bases de conocimiento. Representa la realidad mediante un conjunto de objetos predefinidos. Genera Bases de Datos Normalizadas. Genera aplicaciones para distintas plataformas.

Pruebas unitarias Verifican el funcionamiento de unidades de software Pruebas aisladas Simulación de objetos llamados por el SUT Con acceso al código fuente Pueden involucrar a los desarrolladores

Herramientas xUnit Frameworks para automatización de pruebas unitarias Permiten crear y ejecutar las pruebas Se escriben y controlan los resultados en el mismo lenguaje del SUT Al ejecutar una prueba indican si el SUT pasó o falló

Herramientas xUnit Patrones utilizados Caso de prueba Método que realiza la verificación de cierta funcionalidad o funcionalidades Contexto de las pruebas Conjunto de precondiciones o estados necesarios para correr una prueba Suite de pruebas Conjunto de casos de prueba con el mismo contexto Ejecución de las pruebas Caso de prueba. Método o procedimiento, generado usualmente en el lenguaje del framework, que realiza la verificación de cierta funcionalidad o funcionalidades. Contexto de pruebas. Un contexto de prueba (test fixture) es el conjunto de precondiciones o estados necesitados para correr una prueba. El desarrollador debe armar un buen estado o configuración antes de las pruebas y luego volver al estado original. Suite de pruebas. Es un conjunto de pruebas que comparten el mismo contexto. El orden en que sean ejecutadas las pruebas no debería importar. Ejecución de las pruebas. El método test es el caso de prueba y los métodos setup y teardown inicializan y limpian el contexto de pruebas respectivamente.

Herramientas xUnit Características más importantes Assertion Methods Implementan el Oráculo Incluidas en el código de la prueba Decisiones booleanas Ejecución de suites como operación única Exposición de los resultados No ambiguos Fáciles de entender Semántica de colores: verde = pasa, rojo = falla La especificación de los resultados esperados con invocaciones a métodos de comprobación (Assertion Methods). Estos métodos implementan el oráculo que queda incluido en el código de la prueba. Las decisiones deben ser booleanas y comprobables por el ordenador. También es posible comprobar excepciones esperadas, en cuyo caso la falla es notificada solo si la excepción no se produce. La exposición de los resultados de las pruebas. La ejecución de las pruebas pierde su sentido si no se conocen los resultados. Éstos deben ser percibidos de manera no ambigua y entendidos fácilmente. La prueba se detiene ante la falla, aunque no impide seguir ejecutando el resto de las pruebas. Se utiliza una semántica de colores definida por: verde = pasa, rojo = falla.

JUnit Framework xUnit para Java Es el más utilizado Especificación del Contexto de las pruebas Permite especificar métodos para que corran antes de comenzar la ejecución de las pruebas y luego de finalizadas (setUp y tearDown) Métodos Assertion Provee de Métodos Assertions que validan los resultados de la ejecución de la prueba El más utilizado de los xUnit. Google Trends…

JUnit Visualización de resultados Muestra resultados como texto o modo gráfico IDEs de desarrollo incluyen plug-ins que permiten ejecutar las pruebas y ver los resultados Colores: Verde=Pasa, Rojo=Falla Se muestra Assertion que falló, comparación resultado esperado contra resultado obtenido

JUnit Suite de pruebas Ejecución de un conjunto de pruebas como una única operación Árbol de suites

PBUnit Framework xUnit para Power Builder Basado en JUnit Especificación del Contexto de las pruebas Permite especificar métodos para que corran antes de comenzar la ejecución de las pruebas y luego de finalizadas (setUp y tearDown) Métodos Assertion Provee de Métodos Assertions que validan los resultados de la ejecución de la prueba

PBUnit Suite de pruebas Pueden agruparse varios casos de prueba y correrlos como una única operación

PBUnit Ejecución y visualización de los resultados

GXUnit (Versión 2007) Se verifican objetos Procedure Se construyen conjuntos de pruebas donde se indican las entradas del procedimiento sus salidas esperadas, según los parámetros definidos en las rules Los conjuntos de prueba pueden construirse manualmente o cargarlos desde un XML Al correr las pruebas se deben seleccionar que pruebas quieren ejecutarse El resultado de las pruebas se guarda en un XML y puede verse desde el IDE de desarrollo

GXUnit (Versión 2007)

Objetos GeneXus

Objetos GeneXus Que objetos vamos a probar? Vamos a evaluar la relevancia de los distintos tipos de objetos Los siguientes datos fueron obtenidos a través del analisis de 19 KBs De esas KBs, se sabe que 4 estaban en producción Los datos de las 15 KBs restantes fueron obtenidas a través del GXServer público.

Objetos GeneXus Aca va la grafica

Objetos GeneXus Observaciones: El objeto con mas ocurrencias es el Web Panel El que lo sigue es el Procedure Luego vienen los objetos Transaction, Data Provider y Data Selectors Web Panel, con casi la mitad de objetos (en promedio) dentro de las KBs El objeto que lo sigue es el Procedure, con un poco menos de la mitad de apariciones que el objeto Web Panel.

Objetos GeneXus Discusión: Que tipo de objeto es el más importante? En ocurrencias el Web Panel Basados en nuestra experiencia y por la diversidad de funcionalidades que puede implementar, decidimos que el objeto Procedure es más relevante Modifican la base de datos UTLs File System etc Esta conclusión surge del entendimiento de que la lógica de un Procedure es más completa y rica para analizar con el sentido de desarrollar GXUnit, si bien es muy necesario considerar para el desarrollo de GXUnit el manejo de eventos en los Web Panels. Por ejemplo, un Web Panel no puede modificar la base de datos, mientras que un Procedure puede tanto seleccionar registros de la base de datos como modificar la misma, en este sentido es más compleja la lógica de un Procedure, puesto que por ejemplo, hay que buscar formas de simular la base de datos, ver cómo se comportan las unidades de trabajo lógicas (UTLs), etc.

Objetos GeneXus Business Process Diagram No los contamos Su número es mínimo dentro de las KBs analizadas 1 o 4 ocurrencias en tres de las KBs Es de interés probarlos unitariamente? Podría ser interesante Probar caminos críticos Entrada y salida de los Datos Relevantes Podrían utilizarse pruebas previamente definidas

Objetos GeneXus Más observaciones: Para la implementación: Los objetos Procedure son los que más aparecen en las KBs de producción También son reutilizables y se puede encapsular la lógica para ser probados Para la implementación: No hay conocimiento experto sobre lo que se va a desarrollar Parece mejor enfocarse en el objeto Procedure, para después extender la herramienta Por lo general, toda la lógica compleja, o lo que se desea sea reutilizable se implementa en un objeto Procedure, ya que los mismos puede ser llamados desde otros objetos del mismo tipo, Web Panels, Work Panels, Data Providers, Attribute (desde las fórmulas), reglas es las Transactions, etc.   Vistas las consideraciones anteriores, es recomendable comenzar la implementación de GXUnit pensando principalmente en los objetos Procedure, todos los problemas o vacíos que se encuentren en su desarrollo serán reutilizables para implementar el resto de los objetos. Además, la programación orientada a eventos de los Web Panels puede entorpecer el desarrollo de GXUnit al complicar la programación del mismo. La programación “procedural” de los objetos Procedure puede facilitar la implementación de GXUnit porque resulta más simple e intuitiva la programación para generar código que ayude a probar el objeto unitariamente.

¿Qué es una Unidad? Unidad en Java Java es un lenguaje orientado a objetos, cada objeto tiene sus propiedades y métodos. La unidad de trabajo se refiere a una clase, un método de una clase o un conjunto pequeño de clases. Unidad en Power Builder Es un lenguaje orientado a objetos, cada objeto tiene eventos, funciones y propiedades. La prueba de Unidad se puede dirigir a eventos y funciones del objeto.(Utilizando PBUnit)

¿Qué es una Unidad en GeneXus? Se define como “Unidad” a un objeto GeneXus Tiene sentido probar todos los objetos? Objetos interesantes a probar: Procedure Web Panel Transaction Etc. No podría ser una “Unidad” una subrutina?

Unidad de Prueba en GeneXus Criterio: El objeto debe aportar funcionalidades a las aplicaciones GeneXus No solo contribuir al diseño de la aplicación Ejemplos de los “no unidad”: Theme Language File Tampoco interesan objetos utilizados para modelar estructuras de datos Ej: Table, Data View, Domain, SDTs, Subtype Group Como primer criterio, se puede considerar que para que tenga sentido probar unitariamente el objeto, el mismo debe aportar alguna funcionalidad a las aplicaciones desarrolladas por GeneXus. Por ejemplo, un objeto Theme, no aporta funcionalidad alguna a las aplicaciones GeneXus, sino que simplemente sirve para encapsular ciertas propiedades de diseño de la aplicación, por lo tanto, estos objetos no serían proclives a ser probados unitariamente. Sin embargo, un objeto Procedure puede agregar una variedad de funcionalidades a la aplicación, por ejemplo, modificación de datos, cálculos complejos, etc., por lo que si sería interesante probarlos unitariamente. Otro tipo de objeto GeneXus que no interesa probar, es el tipo de objetos que se utilizan para definir estructuras de datos (Table, Data View, Domain, Structured Data Type, Subtype Group), estos objetos son utilizados por GeneXus para determinar relaciones entre los datos, pero no tiene ningún sentido que consideremos estos objetos como proclives a ser probados unitariamente. Además este tipo de objetos en realidad no aporta funcionalidad a las aplicaciones por si solos, sino que agregan funcionalidades a través de su uso en otros objetos.

Unidad de Prueba en GeneXus Objeto Attribute: Solo tiene sentido probarlos cuando están asociados a una transacción Serán probados en ese contexto External Object: Desarrollados con código nativo Pueden realizarse pruebas de caja negra Las pruebas quedan como documentación del objeto Con los objetos de tipo Attribute sucede algo interesante, porque si bien puede ser importante permitir probar unitariamente algunos atributos, por ejemplo, en el caso de que estos sean de tipo fórmula, la prueba carece de sentido si estos atributos no están ligados a un objeto de tipo Transaction. Por lo tanto, se considera que no tiene sentido probar los objetos Attribute de forma unitaria, sino que los mismos serán probados en contextos de interés, por ejemplo, en las reglas de una Transaction, o en un Procedure. En el caso de los objetos External Object, se considerara que fueron probados con anterioridad y se utilizaran solamente como una herramienta para agregar funcionalidad a otros objetos. Las instancias de Pattern no se consideraran proclives a ser probadas unitariamente, puesto que las mismas en realidad, tienen como única finalidad encapsular lógica para aplicar a los objetos Transaction determinados patrones de diseño, y por lo general, generan otros objetos que implementan dicha lógica, objetos que si podrían ser de interés para probar unitariamente. Por ende, lo que realmente sería interesante de probar unitariamente serían los objetos generados por el patrón.

Unidad de Prueba en GeneXus Instancias de Pattern: Aún en discusión: Un Pattern en principio encapsulan lógica Que se prueba unitariamente? El código generado? Se realizan pruebas unitarias para cada componente de la instancia? Con los objetos de tipo Attribute sucede algo interesante, porque si bien puede ser importante permitir probar unitariamente algunos atributos, por ejemplo, en el caso de que estos sean de tipo fórmula, la prueba carece de sentido si estos atributos no están ligados a un objeto de tipo Transaction. Por lo tanto, se considera que no tiene sentido probar los objetos Attribute de forma unitaria, sino que los mismos serán probados en contextos de interés, por ejemplo, en las reglas de una Transaction, o en un Procedure. En el caso de los objetos External Object, se considerara que fueron probados con anterioridad y se utilizaran solamente como una herramienta para agregar funcionalidad a otros objetos. Las instancias de Pattern no se consideraran proclives a ser probadas unitariamente, puesto que las mismas en realidad, tienen como única finalidad encapsular lógica para aplicar a los objetos Transaction determinados patrones de diseño, y por lo general, generan otros objetos que implementan dicha lógica, objetos que si podrían ser de interés para probar unitariamente. Por ende, lo que realmente sería interesante de probar unitariamente serían los objetos generados por el patrón.

Características de GXUnit Se Necesita: Que esté integrada al entorno de GeneXus Es más sencillo utilizar la herramienta Se pueden considerar las preferencias de desarrollo de la KB Pruebas veloces Almacenar pruebas Guardar los resultados Cuando la herramienta de testing unitario no está integrada, trae problemas.

Cómo Desarrollar GXUnit? Utilizando Extensiones Disponibles desde la versión X de GeneXus Desarrolladas en C# y utilizando el GeneXus SDK El entorno de desarrollo se encuentra implementado como una colección de paquetes. Este diseño, permite que GeneXus sea fácilmente extensible, permitiendo agregar libremente módulos al programa para implementar las más diversas funcionalidades, los módulos a agregar pueden tener cualquier complejidad, desde módulos que agreguen una opción al menú, hasta módulos que generen código, en teoría, no existen límites en cuanto a las funcionalidades que podrían llegar a implementarse para extender GeneXus ya que en principio, no habría diferencia entre los módulos desarrollados por Artech, los desarrollados para implementar las nuevas funcionalidades.

Ejemplo de Extension Una de las extensiones de ejemplo que acompañan el SDK de GeneXus es Daily Dilbert, esta extensión consiste básicamente en una ventana de herramientas GeneXus que muestra HTML creado dinámicamente para mostrar fuentes RSS utilizando transformaciones XSL.

¡Muchas Gracias! ¿Preguntas?