Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Desarrollo Dirigido Por Pruebas - TDD.

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 2

DESARROLLO DIRIGIDO POR PRUEBAS (TDD).

Integrantes:
-Jonnathan Pearanda.
-Pamela Pesantez.
Concepto: El desarrollo dirigido por pruebas (TDD), Test-Driven Development,
desarrollado por Kent Beck en 2002; es un proceso de desarrollo de software que se
basa en la idea de desarrollar pruebas, codificar y refactorizar el cdigo construido, esto
quiere decir que el cdigo se construye incrementalmente, junto a una prueba.
No se avanza al siguiente incremento si el cdigo diseado no pasa la prueba.
Este proceso se introdujo como parte de los mtodos giles, pero se lo puede usar en
procesos desarrollados por un plan.
Los pasos que realiza este proceso son:
En primer lugar, diseamos y escribimos los casos de prueba y las pruebas unitarias en
base a requisitos del software y a la arquitectura del proyecto.
En segundo lugar, codificamos la aplicacin de tal manera que el cdigo implementado
cumpla los test diseados previamente.

Fases relevantes del TDD en el modelo de desarrollo:


Fase de Diseo: Se definen los casos de prueba a implementar partiendo de los
requerimientos.
Fase de Desarrollo: Para cada una de las tareas de una iteracin se implementan los
casos de prueba traducindolos en test unitarios. Durante la tarea se disean nuevos
test unitarios y se ejecutan todas las pruebas.
Fase de Produccin: El mantenimiento del producto exige cambios y/o refactorizaciones
que van asociadas a nuevos de test unitarios.
Roles de TDD:

Dueo del producto: Su misin es pedir lo que necesita (no el cmo, sino el qu)
y aceptar o pedir correcciones sobre lo que se le entrega.
Cliente: Es el dueo del producto y el usuario final.

Analista de negocio: Tambin es el dueo del producto porque trabaja codo a


codo con el cliente y traduce los requisitos en tests de aceptacin para que los
desarrolladores los entiendan, es decir, les explica qu hay que hacer y resuelve
sus dudas.
Arquitecto del software: Es la persona capaz de tomar decisiones de diseo,
adems se le da la capacidad de poder hablar directamente con el cliente y
entender los requisitos de negocio.
Desarrolladores: Toman la informacin del analista de negocio y deciden cmo
lo van a resolver e implementar una solucin. Aparte de escribir cdigo, los
desarrolladores deben tener conocimientos avanzados sobre el uso y diseo de
interfaces de usuario.
Administradores de sistemas: Se encargan de satisfacer las necesidades y
servicios que necesitan los desarrolladores para poder implementar el proyecto.

Caractersticas:

Cobertura de cdigo: Cualquier segmento de cdigo que escriba debe tener al


menos una prueba asociada. Por lo tanto, se asegura de que cualquier cdigo
en el sistema se ejecuta realmente.
Depuracin simplificada: Cuando falla una prueba, es evidente dnde se
encuentra el problema. Es preciso comprobar y modificar el cdigo recin escrito.
No se requieren herramientas de depuracin para localizar el problema.
Documentacin del sistema: Las pruebas actan como una forma de
documentacin que describen lo que debe hacer el cdigo. Leer las pruebas
suele facilitar la comprensin del cdigo.

Ventajas:

La calidad del software aumenta.


Conseguimos cdigo altamente reutilizable; ya que se aplica programacin
modular.
El trabajo en equipo se hace ms fcil, une a las personas.
Escribir el test antes del cdigo nos obliga a escribir el mnimo de funcionalidad
necesaria.
Los tests son la mejor documentacin a la hora de entender que misin cumple
el software.

Desventajas:

En el caso de que la aplicacin o sistema a realizar tenga una cantidad grande


de requisitos el desarrollo guiado por estas pruebas se vuelve tedioso y de
muchos costos.
El tiempo de desarrollo empleado en este tipo de pruebas es algo que puede
volverse muy extenso.
Para poder avanzar en el desarrollo de la aplicacin si no se cumple un requisito
no se puede pasar al otro.

El desarrollo basado en pruebras (TDD) es muy usado por grupos de desarrollo de


metodologas giles, est muy probado y combina bien con Xtreme Programming
y Scrum, por lo que se puede usar en proyectos de cualquier tamao.

También podría gustarte