Pruebas de Unidad, Estándares de codificación y Generación automática de código Serrano Cuayahuitl Víctor Hugo Facultad de Ciencias Básicas, Ingeniería y Tecnología Universidad Autónoma de Tlaxcala Resumen: Al desarrollar un nuevo software, la primera etapa de pruebas a considerar es la etapa de pruebas unitarias, estás pruebas nos permiten determinar si un modulo del programa está listo y correctamente terminado. Las pruebas de unidad son una manera de manejar los elementos de prueba, puesto que se centra la atención en unidades más pequeñas del programa. Facilitan la tarea de eliminar errores, puesto que cuando se encuentra un error, se sabe que existe en un módulo particular. 1. INTRODUCCIÓN En el desarrollo de aplicaciones, uno de los métodos más utilizados para realizar pruebas a nuestro software es el llamado pruebas de unidad. La base de este método es el hacer pruebas en pequeños fragmentos de nuestro programa. Estos fragmentos deben ser unidades estructurales de nuestro programa encargados de una tarea específica, en programación procedural u orientada a objetos podemos afirmar que estas unidades son los métodos o las funciones que tenemos definidos. Tras realizar estas pruebas sobre los elementos unitarios de nuestro programa podremos eliminar gran parte de los errores que podría contener. Las pruebas unitarias no revelan errores en la integración de las partes unitarias ni tampoco otros problemas como el bajo rendimiento de las aplicaciones o problemas derivados del sistema sobre el que está ejecutándose nuestro programa. Una unidad es una parte comprobable de una solicitud de desarrollo. 2.2. Objetivos: Verificar la funcionalidad y estructura de cada componente una vez que ha sido codificado. Proveer a los programadores con alguna evidencia objetiva de lo que han producido. Quitar tantas inconsistencias como sea posible antes de las pruebas de integración del proyecto. 2.3. Características Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos: Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continúa. Completas: deben cantidad de código. Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua. 2. PRUEBAS DE UNIDAD Las pruebas de unidad son un tipo de pruebas de software que consisten en un proceso para probar los subprogramas, subrutinas, procedimientos y clases en un programa. El programador verifica cada unidad de código fuente contra su especificación. cubrir la mayor Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra. Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc. Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función. 2.1. Ventajas El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas básicas: 1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores. 2. Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración. 3. Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo. 4. Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock para simular el comportamiento de objetos complejos. 5. Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos. 2.4. Proceso de una Prueba de Unidad Para llevar a cabo una prueba de unidad se recomienda realizar: 1. El plan de pruebas de unidad. 2. Realizar el diseño de las pruebas. 3. Definir el entorno de prueba, y las instrucciones del operador. 4. Ejecutar las pruebas. 5. Identificar los datos de prueba. 6. Analizar los resultados 3. ESTANDARES DE CODIFICACIÓN Los estándares de codificación son pautas de programación que no están enfocadas a la lógica del programa, sino a su estructura y apariencia física para facilitar la lectura, comprensión y mantenimiento del código. Adoptar un estándar permite enfocarse más en el código que en el formateo del mismo porque a la larga se vuelve mecánico “Así se escribe el código y punto”. Asimismo, aporta consistencia pues las diferentes porciones de código guardan un patrón que se puede reconocer. Además mejora la legibilidad del código. Permite que otras personas puedan colaborar más eficazmente pues la “redacción” del código no les resulta incomoda. En consecuencia, el mantenimiento es menos pesado como resultado de los aportes anteriormente mencionados. 3.1. Ventajas Asegurar la legibilidad del código entre distintos programadores. Proveer una guía para el encargado del mantenimiento/actualización del sistema, con código claro y bien documentado. Facilitar la portabilidad plataformas y aplicaciones. 3.2. Especificaciones generales estándares de codificación. entre en los Existen diversas formas de realizar la estandarización de código de acuerdo a cada lenguaje, sin embargo, podemos hacer una generalización de los puntos más importantes a considerar, entre los que se encuentran: Estructuras de control. Deben tener paréntesis de apertura, utilización de llaves. Esto mejora la legibilidad y disminuye la posibilidad de errores lógicos al agregar nuevas líneas de código Llamadas a funciones. Deben ser llamadas sin espacio entre el nombre de la función, el paréntesis de apertura y el primer parámetro. Comentarios. Se aconseja el uso de comentarios en línea para facilitar la comprensión del código. Cada programa deberá comenzar con un comentario que incluya: Autor Fecha Objetivo, o problema que resuelve el programa Fecha de creación y fecha de modificación. Definición de funciones. Cada función debe tener un encabezado que contenga: Objetivo de la función. Comentarios de apoyo a variables, llamadas a función. Explicación de uso de argumentos (parámetros). Explicación de uso de valores devueltos (de retorno). El nombre debe ser lo más descriptivo posible, Se debe evitar el uso de abreviaturas, Colocar los argumentos con valores por defecto, al final de la lista. Siempre intentar retornar un valor significativo. La llave de inicio de la función se coloca en la línea siguiente. Definición de Clases Nombre de identificadores ó variables. (variables, arreglos, matrices, apuntadores, funciones, clase). Deben tener un nombre significativo. Para nombres frecuentes o largos, se recomienda usar abreviaturas. Cada identificador de función, variable o procedimiento deberá ser precedido por la abreviación del tipo de dato de que es la variable. Generales. No manejar en los programas más de una instrucción por línea. Declarar las variables en líneas separadas Añadir comentarios descriptivos junto a cada declaración de variables. Las sangrías tendrán una longitud de tres espacios. 4. GENERACIÓN CÓDIGO AUTOMATICA DE Actualmente los equipos de desarrollo cuentan con lenguajes de modelado, los cuales posibilitan la construcción de modelos que, se convierten en herramientas que contribuyen en la evolución de la generación de código. UML es el lenguaje de modelado de mayor uso en la actualidad. Con UML es posible modelar los aspectos estáticos y dinámicos de un sistema, y en diferentes niveles de detalle. En el caso particular de UML, parte de las relaciones necesarias se han presentado en herramientas CASE comerciales y académicas. 4.1. Herramientas CASE Estas herramientas permiten la generación de código a partir del diagrama de clases con resultados muy similares, apreciables en la estructura del código, la cual está formada por la declaración de las clases, atributos y operaciones. 4.2. 1. 2. 3. 4. Ejemplos de Herramientas CASE Togeteher TM Rational Rose TM Fujaba Enterprise Architect 5. REFERENCIAS. [1]. http://www.xuletas.es/ficha/prueba-dela-unidad/ [2]. http://www.novanebula.net/blog/archives /99-Unit-testing-pruebas-unitarias.html [3]. http://www.calidadysoftware.com/testing /pruebas_unitarias1.php [4]. http://es.wikipedia.org/wiki/Prueba_unita ria