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 Buenas Tardes, gracias por venir. somos tres estudiantes del curso proyecto de grado. La idea es presentarles el estado del arte del proyecto.

Agenda Introducción Lenguajes Generadores de Aplicaciones Pruebas Unitarias y Herramientas Xunit ¿Qué consideramos unidad? Objetos GeneXus Características de GXUnit ¿Cómo desarrollar GXUnit? El primer punto es una introducción donde vamos hablar acerca de los objetivos de esta presentación y los antecedentes del proyecto gxunit. Luego hablamos sobre lenguajes generadores de aplicaciones, mas concretamente sobre genexus y power builder, dado que vamos a a construir una herramienta de pruebas unitarias para un lenguaje generador de aplicaciones. Luego entramos en detalle de Pruebas Unitarias y Herramientas XUnit Después se plantea la interrogante de lo q se considera una unidad de prueba. A continuación vemos los Objetos GeneXus y sus prioridades. Finalizando planteamos las Características básicas que debe tener la herramienta GXUnit según nuestro punto de vista Y Cómo encarar el desarrollo de GXUnit

Introducción Objetivos de la Presentación Exponer investigación en: Pruebas Unitarias Herramientas xUnit Objetos GeneXus Recibir retroalimentación Requerimientos para la construcción de la herramienta El objetivo de la presentación es mostrarles lo que hemos investigado acerca de pruebas unitarias en lenguajes generadores de aplicaciones, Herramientas xUnit y objetos genexus, y recibir retroalimentación y nuevos requerimientos para la construcción de la herramienta

Introducción GXUnit GXUnit tuvo su origen en el año 2003 En el año 2004 se formalizó la propuesta en la línea 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” La propuesta GXUnit tuvo su origen en el año 2003 cuando Enrique Almeida anunció su objetivo de crear una herramienta de automatización de pruebas unitarias en GeneXus. En el año 2004 formalizó su propuesta caracterizando la misma en la línea de las herramientas xUnit. En julio de 2007 se propuso el proyecto GXUnit para su desarrollo en el ámbito del curso “Proyecto de Ingeniería de Software” donde participaron como clientes Uruguay Larre Borges, Almeida y Alejandro Araujo. donde se logró la construcción de un prototipo que mas adelante se menciona. En el año 2010 se propuso el desarrollo del proyecto en el ámbito del curso “Proyecto de Grado” y aquí estamos

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” Beizer, B.: "Carta a swtest-discuss“ La identificación temprana de errores reduce el esfuerzo de corrección y el costo de los proyectos En GeneXus las pruebas unitarias aún requieren mucho tiempo y esfuerzo por parte del desarrollador Cual es la motivación de contar con una herramienta de apoyo a las pruebas unitarias en GeneXus. Boris Beizer menciona (DIAPOSITIVA) Además La identificación temprana de errores reduce el esfuerzo de corrección y el costo de los proyectos Y En GeneXus las pruebas unitarias aún requieren mucho tiempo y esfuerzo por parte del desarrollador, esto según nuestra experiencia como desarrolladores

Generadores de Aplicaciones GeneXus y Power Builder Lenguajes declarativos, generadores de aplicaciones Orientados a especificar Sistemas de Información Soportan arquitecturas cliente/servidor, distribuidas y web Brindan facilidades para el acceso a Bases de Datos, diseño de reportes e interfaz de usuario Antes de comenzar con los conceptos y herramientas de pruebas unitarias y dado que gxunit es para genexus buscamos lenguajes similares con el fin de conocer cómo realizaban pruebas unitarias. Se elige Power Builder (DIAPOSITIVA) tal como genexus. Además en la encuesta de la revista Software Gurú se ubicó en la segunda posición tras genexus, como uno de los lenguajes declarativos generadores de aplicaciones favoritos, la idea es investigar como se realizan pruebas unitarias en Power Builder con el fin de utilizar el conocimiento adquirido en la construcción de GXUnit. Mas adelante se habla de PBUnit También estuvimos viendo otras herramientas de desarrollo como sap peoplesoft y open edge pero estas no preveen buena documentación ni ofrecían versiones de prueba, por eso fueron descartadas.

Conceptos - Pruebas unitarias Verifican el funcionamiento de unidades de software Con acceso al código fuente (caja blanca) Involucra a los desarrolladores Es importante la velocidad de las pruebas Independizar unidades del resto del sistema Simulación de objetos Como mencionaba anterirmente investigamos acerca de las pruebas unitarias, estas verifican el funcionamiento de unidades de software. Más adelante se indicará a qué se le denomina unidad, y específicamente que es unidad en GeneXus. El acceso a código fuente es usual, también existen las pruebas unitarias de caja negra. Las pruebas unitarias deben realizadas por los desarrolladores. Las pruebas unitarias deben ser veloces, para así poder correrlas constantemente cada vez que se realiza un cambio en la unidad. Deben ser concretas. Si la prueba demora mucho probablemente no se este eligiendo bien los datos de prueba o no se este verificando una unidad. Se intenta probar la unidad independientemente del resto del sistema. Para esto se utiliza la simulación de objetos a los que llama la unidad. Esta simulación puede realizarse por medio de stubs, mocks, etc.

Herramientas xUnit Frameworks para automatización de pruebas unitarias Permiten crear y ejecutar las pruebas Se describen y controlan los resultados en el mismo lenguaje del SUT Al ejecutar una prueba indican si pasó o falló Ahora vamos a hablar sobre frameworks xUnit Pero por qué existen los frameworks? Se pueden hacer pruebas unitarias sin frameworks pero los frameworks proveen un montón de cosas ya hechas para realizar pruebas Permiten mantener las pruebas, ir almacenándolas y agrandando el paquete de pruebas, proveen reportes ya diseñados estandarizados Todo esto sino se tendría que hacer a mano. xUnit se refiere a un conjunto de frameworks para la automatización de pruebas unitarias que permite crea y ejecutar las pruebas. Las pruebas se realizan y se controlan sus resultados en el mismo lenguaje que el sistema que se está verificando. Luego de ejecutar una prueba el framework indica usualmente con los colores verde o rojo si ésta pasó o falló respectivamente.

Herramientas xUnit Conceptos utilizados Caso de prueba Porción de código que verifica 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. Porción de código, generado 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. --Contexto: Datos de prueba y estado del ambiente. Que si se necesita cargar un archivo este se encuentre donde se espera, etc. 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. Se debe poder ejecutar un suite de pruebas como una operación atómica 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 y PBUnit Frameworks xUnit para Java y Power Builder Junit es el más utilizado, PBUnit 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 métodos Assertions que validan los resultados de la ejecución de la prueba Suite de pruebas El más utilizado de los xUnit. Google Trends… Pueden agruparse varios casos de prueba y ejecutarlos como una única operación Java es el lenguaje más utilizado (19%) BPUnit obsoleto y no integrado en el entorno de desarrollo, una de las cosas por lo que NUnit no tuvo éxito

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 casos de prueba pueden construirse manualmente o cargarlos desde un XML El resultado de las pruebas se guarda en un XML y puede verse desde el IDE de desarrollo Está obsoleto A arreglar, ver la sintaxis de esta ppt. No se soportan SDT en ninguno de los 2 grupos, un grupo soportaba solo 2 parametros de entrada y uno de salida, mientras que el otro era dinámico

GXUnit 2007 Grupo1

GXUnit 2007 Grupo1

GXUnit 2007 Grupo2

GXUnit 2007 Grupo2

GXUnit 2007 Grupo2

¿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) La primera pregunta que nos hacemos al pensar en pruebas unitarias es qué es una unidad… Ahora que hicimos un repaso de los conceptos de pruebas unitarias y herramientas xUnit nos planteamos la interrogante de que se considera una unidad de prueba

Unidad de Prueba en GeneXus Tomamos como “unidad” a un objeto GeneXus ¿Todos los objetos? Temas, Lenguage … Objetos utilizados para modelar estructuras de datos External Object Componentes de objetos ¿Atributos fórmula? Eventos, Subrutinas Grupos de Objetos Pattern Bussines Process Diagram 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 (otros objetos: Theme, Language, File). 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. 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. Que se probaría? El código generado? Se realizarían pruebas unitarias para cada componente de la instancia? External Object: Desarrollados con código nativo, Pueden realizarse pruebas de caja negra, Las pruebas quedan como documentación del objeto

Objetos GeneXus

Objetos GeneXus

Objetos GeneXus Los siguientes datos fueron obtenidos a través del análisis 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 El objeto con mas ocurrencias es el Web Panel El que lo sigue es el Procedure, aunque Los objetos Procedure son los que más aparecen en las KBs de producción. 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. 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. Tambien decir que por algo el proyecto anterior tomo como base el procedure. 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. Tambien ver el tema de la interfaz gráfica de los webpanels y transactions.

Consideraciones Conviene comenzar a desarrollar pensando principalmente en los objetos Procedure Tener siempre en cuenta el funcionamiento de los objetos Web Panel al momento de definir la arquitectura ¿Business Process Diagram? 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? Probar caminos críticos Entrada y salida de los Datos Relevantes Podrían utilizarse pruebas previamente definidas 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. También complica el hecho de tener que tener en cuenta aspectos de interfaz de usuario.

Características de GXUnit Integrado al entorno de GeneXus Es más sencillo utilizar la herramienta Se pueden considerar las preferencias de desarrollo de la KB Pruebas veloces Generación automática de pruebas Almacenar/Exportar/Importar pruebas y resultados Simulación de Objetos GeneXus (Mocks) Pruebas embebidas en el código Cuando la herramienta de testing unitario no está integrada, trae problemas. La idea es que todo este almacenado dentro de la kb. Embebido en el lengaje.

¿Cómo Desarrollar GXUnit? Utilizando Extensiones Disponibles desde la versión X de GeneXus Desarrolladas en C# y utilizando el GeneXus SDK Basado en las implementaciones de PIS (2007) ¿Asserts? ¿Extendiendo el lenguaje? ¿Utilizando External Objects? 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.

¡Muchas Gracias! ¿Preguntas? ¿Respuestas? ¿Sugerencias? Posibles preguntas: ¿Está bien considerar que la unidad es un objeto? Podría considerarse por ejemplo porciones de código, como subrutinas, etc. ¿Qué objeto es el más relevante a probar? ¿Cómo probar los distintos objetos? Web panels por ejemplo. ¿Sería recomendable que la herramienta permitiera extensibilidad para nuevos objetos?