Presentación del estado del arte

Presentación del tema: "Presentación del estado del arte"— Transcripción de la presentación:

1 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

2 Agenda Introducción Lenguajes Declarativos
Pruebas Unitarias y Herramientas XUnit Objetos GeneXus ¿Qué consideramos unidad? Características de GXUnit ¿Cómo desarrollar GXUnit?

3 Introducción Objetivos de la Presentación
Exponer investigación en: Pruebas Unitarias sobre Lenguajes Declarativos 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 declarativos, Herramientas xUnit y objetos genexus, y recibir retroalimentación con el fin de cristalizar en la herramienta gxunit

4 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” de la Facultad de Ingeniería de la Universidad de la República. En el año 2010 se propuso el desarrollo del proyecto en el ámbito del curso “Proyecto de Grado”

5 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 (DIAPOSITIVA)

6 Lenguajes Declarativos
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 A arreglar, cambiar el enfoque de la diapositiva, hablar más de porque analizamos pb comparativamente con genexus, sacar lo de 4 gl lo más posible. Hablar más del mdd. Dado que genexus es un lenguaje declarativo comenzamos buscando lenguajes similares con el fin de conocer cómo realizaban pruebas unitarias. Se elige Power Builder dado que es similar a GeneXus (DIAPOSITIVA) 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 favoritos, la idea es investigar como se realizan pruebas unitarias en PB con el fin de utilizar el conocimiento adquirido en la construcción de GXUnit

7 Pruebas unitarias Verifican el funcionamiento de unidades de software
Deben ser independientes del resto del sistema Simulación de objetos Con acceso al código fuente (caja blanca) Involucra a los desarrolladores Es importante la velocidad de las pruebas Las pruebas unitarias 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. 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. 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.

8 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ó 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. A arreglar, revisar bien el formato de las ppt.

9 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. 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.

10 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.

11 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

12 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á hecho para una versión que ya no se mantiene (“Arreglar bien aca”) A arreglar, ver la sintaxis de esta ppt.

13 Objetos GeneXus

14 Objetos GeneXus ¿Qué objetos vamos a probar?
Vamos a evaluar la relevancia de los distintos tipos de objetos 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

15 Objetos GeneXus Aca va la grafica

16 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.

17 Objetos GeneXus ¿Qué objetos son los más relevantes?
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. Tambien decir que por algo el proyecto anterior tomo como base el procedure. A arreglar: darle más color a la presentación

18 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 Mejorar la redacción.

19 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 (cambiarlo, queda muy bruto) 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.

20 ¿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) Capaz sacar esto porque queda colgado.

21 ¿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 por ejemplo?

22 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.

23 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.

24 Unidad de Prueba en GeneXus
Instancias de Pattern: Aún en discusión: Los Pattern en principio encapsulan lógica Cual sería el objetivo.“”””””””¿Qué 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.

25 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.

26 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.

27 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.

28 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. A arreglar: ESTO debería estar más al final, aca iría algo así como: “el objetivo es construir una herramienta/s para hacer pruebas unitarias en genexus”, ser más conciso y concreto.

29 ¡Muchas Gracias! ¿Preguntas? Respuestas