Herramientas case

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería - Sede Trelew Cátedra: INGENIERÍA DE SOFTWARE

Carrera: Licenciatura en Informática - AÑO: 2011



Pág. 1

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería - Sede Trelew Cátedra: INGENIERÍA DE SOFTWARE

Carrera: Licenciatura en Informática - AÑO: 2011
Índice. Pág.Objetivo………………………………………………………………………………………………………….…3 Ejercicio 1……………………………………………………………………………………………………….....3 Ejercicio 2……………………………………………………………………………………………………….....11 Ejercicio 3……………………………………………………………………………………………………….....15

Pág. 2

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería - Sede Trelew Cátedra: INGENIERÍA DE SOFTWARE

Carrera: Licenciatura en Informática - AÑO: 2011 OBJETIVO: Investigar herramientasque soporten distintas fases del ciclo de vida del software. ENUNCIADO:

1. Realizar un análisis detallado de TDD (Test-Driven Development) e investigar al menos una herramienta de soporte.
Desarrollo guiado por pruebas, o Test-driven development (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización(Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En Primer Lugar se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Delinglés: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente. Para que funcione el desarrollo guiado por pruebas, el sistema que se programa tiene que ser lo suficientemente flexible como para permitir que sea probado automáticamente. Cada prueba serásuficientemente pequeña como para que permita determinar unívocamente si el código probado pasa o no la prueba que esta le impone. El diseño se ve favorecido ya que se evita el indeseado "sobre diseño" de las aplicaciones y se logran interfaces más claras y un código más cohesivo. Frameworks como JUnit proveen de un mecanismo para manejar y ejecutar conjuntos de pruebas automatizadas. Ciclo dedesarrollo conducido por pruebas. Antes de comenzar el ciclo se debe definir una lista de requerimientos. Luego se comienza el siguiente ciclo: 1. Elegir un requerimiento: Se elige de una lista el requerimiento que se cree que nos dará mayor conocimiento del problema y que a la vez sea fácilmente implementable. 2. Escribir una prueba: Se comienza escribiendo una prueba para el requerimiento. Para elloel programador debe entender claramente las especificaciones y los requisitos de la funcionalidad que está por implementar. Este paso forza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces. 3. Verificar que la prueba falla: Si la prueba no falla es porque el requerimiento ya estaba implementado o porque la prueba es errónea. 4. Escribir laimplementación: Escribir el código más sencillo que haga que la prueba funcione. Se usa la metáfora "Déjelo simple". 5. Ejecutar las pruebas automatizadas: Verificar si todo el conjunto de pruebas funciona correctamente. 6. Eliminación de duplicación: El paso final es la refactorización, que se utilizará principalmente para eliminar código duplicado. Se hacen de a una vez un pequeño cambio y luego secorren las pruebas hasta que funcionen. 7. Actualización de la lista de requerimientos: Se actualiza la lista de requerimientos tachando el requerimiento implementado. Asimismo se agregan requerimientos que se hayan visto como necesarios durante este ciclo y se agregan requerimientos de diseño (P. ej que una funcionalidad esté desacoplada de otra). Tener un único...