6.3. Desarrollo e Implementación de las Pruebas Unitarias

[[Nombre de la institución]]
Desarrollo e Implementación de las Pruebas de Unidad
[[fecha]]
Versión 1.0
[[Nombre del proyecto]]
1
1.1
Introducción
Propósito del documento
<Insertar los propósitos particulares del documento para la institución>
Actualmente la pauta en el desarrollo de software la marca la eficiencia, esto implica resultados
rápidos y de buena calidad. Una de las técnicas orientada a mejorar la eficiencia dentro de la
programación extrema es la de escribir primero las pruebas, lo cuál ha traído como resultado una
metodología denominada Desarrollo Guiado por Pruebas (TDD).
La presente herramienta muestra una guía para el desarrollo y la implementación de estas
pruebas, también se presentan dos de los frameworks que automatizan las pruebas de aceptación
y las pruebas unitarias, para mayor información respecto a cada uno de ellos y de la herramienta
en general ver: Pruebas_Unitarias.doc
2
Pruebas Unitarias
Básicamente una prueba unitaria es equivalente a una prueba de dispositivos físicos, son aplicadas
a cada módulo aislado con el objetivo de comprobar su comportamiento.
Un desarrollador escribe pruebas método a método, y las escribe bajo las siguientes
circunstancias:
 Si la interfaz para un método no está clara, escribe una prueba antes de escribir el método.
 Si la interfaz está clara, pero imagina que la implementación podría ser un poco menos
complicada, escribe una prueba antes de escribir el método.
 Si piensa en una circunstancia no usual en la cual el código debiera funcionar conforme
está escrito, escribe una prueba para comunicar la circunstancia.
 Si encuentra un problema posterior, escribe una prueba que aísla el problema.
 Si está haciendo refactoring en algún código, y no está seguro de cómo debe ser su
comportamiento, y todavía no hay una prueba para dicho comportamiento, escribe una
primera prueba.
Cuando se escriben pruebas se pretende que éstas aseguren que el elemento en pruebas cumple
con un contrato previamente definido, esto aclara si el código respeta el contrato y si el contrato
significa lo que se cree que significa.
Escribir las pruebas primero es una técnica de programación que necesita práctica. Se debe
aceptar el hecho de que no se verán resultados milagrosos durante una noche. Como cualquier
cosa nueva, cuánto más se practique, los resultados obtenidos serán mejores.
Las pruebas unitarias escritas por el desarrollador siempre funcionan al 100%, si falla una de las
pruebas de unidad, nadie del equipo tiene trabajo más importante que corregir las pruebas.
3
Método de trabajo centrado en las pruebas de unidad
La secuencia de pasos para elaborar código centrado en las pruebas de unidad son los siguientes:
[[Nombre del Proyecto]]
Página 1 de 2
[[Nombre de la institución]]
Desarrollo e Implementación Pruebas Unitarias
Versión 1.0
1.
2.
3.
4.
5.
6.
7.
[[Autor]]
Crear una prueba de unidad
Compilar la prueba de unidad
Implementar el código para que la prueba de unidad compile
Ejecutar la prueba de unidad y comprobar que falla
Implementar el código necesario para pasar la prueba de unidad
Ejecutar la prueba de unidad y comprobar que el código pasa
Repetir desde el paso uno hasta que se haya probado e implementado toda la
funcionalidad.
Este ciclo de siete pasos debería tener una duración de entre cinco y diez minutos, sin embargo
puede suceder que en cada ciclo sea necesario añadir nueva funcionalidad al sistema. Cuando
esto sucede es muy importante reiniciar el ciclo para la nueva funcionalidad, en otras palabras, el
desarrollador siempre debe tener en mente que antes de codificar algo nuevo hay que crear
previamente su prueba de unidad correspondiente.
4
Almacenamiento y mantenimiento de las Pruebas de Unidad
Las pruebas de unidad son almacenadas en el repositorio junto con su código asociado. El código
que no disponga de pruebas de unidad no debe ser introducido en el repositorio, y si en algún
momento se descubre código en el repositorio que no dispone de ellas éstas deben ser creadas
inmediatamente.
Para automatizar en la medida de lo posible todos los procesos asociados a las pruebas de unidad
es imprescindible utilizar un framework de pruebas de unidad, herramienta que se encuentra
disponible para la mayoría de los lenguajes de programación.
Los frameworks existentes son llamados XUnit, donde la letra X, es un lugar para diferentes letras
y representa los diferentes lenguajes de programación. Por ejemplo, JUnit representa el marco de
trabajo de prueba de Java, SUnit corresponde al de Smalltalk, NUnit es el de las aplicaciones
Microsoft .NET, HTTPUnit para las aplicaciones html y así sucesivamente.
Un breve detalle de JUnit y NUnit se encuentra disponible en la herramienta señalada en la
introducción, para mayor información de cada una de ellas ver:
JUnit: www.junit.org.
Nunit: www.nunit.org.
[[Nombre del Proyecto]]
[[Nombre de la institución]]
Página 2 de 2