Pruebas de Unidad, Estándares de codificación y Generación

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