[[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