VERIFICACIÓN Y VALIDACIÓN DE SOFTWARE

TDD & BDD

_______________________________________________________

Daniel Ortiz Manjarrés Mauricio Pérez Cárdenas

 Daniel Ortiz Manjarrés
__________________________________

TDD
___________________________________________________________

Test Driven Development

Se basa en traducir los requisitos del software en casos
de prueba, para poder primero escribir sus test
__________________________________

luego realizar la implementación necesaria para que estos test

pasen, y finalmente refactorizar el código escrito
Fase Roja.
Se escriben los test que cubren los casos de prueba
(provenientes de un requisito).

Estos test por norma general van fallar, ya que no

existe todavía la implementación necesaria.

Cuando un test falla, este se ve de color rojo, de allí de

esta fase.
 Se escribe código con el único objetivo de pasar los
test (pasar del color rojo del test fallido, al verde del
test aprobado).

Fase Verde.
Durante esta fase no se van a tener en cuenta las
buenas prácticas a la hora de desarrollar código, lo
importante (por ahora) en es pasar los test.
 Se va a revisar el código escrito para que cumpla con
las buenas prácticas del código.

Se podría decir que es pasar a limpio el código

realizado en la fase anterior.

En esta fase se juega con la ventaja de que con

cualquier modificación que se realice al código, se
puede comprobar si se siguen pasando los test o no.

Fase Azul.
Para poder aplicar TDD, se deben describir
correctamente las historias de usuario.
___________________________________________
 Para poder aplicar TDD, se deben describir
correctamente las historias de usuario.
___________________________________________

• Los requisitos deben quedar claros, y a partir de estos formar los casos
de prueba que espera el cliente.

• Si no se realiza correctamente la traducción de a , aplicar TDD va a ser

un desastre.
 Para poder aplicar TDD, se deben describir
correctamente las historias de usuario.
___________________________________________
1. Haciendo los test primero, se evita que se dejen para el final, se olviden
casos de prueba, o se recorten por falta de tiempo.

2. Los test a cumplir se basan en los casos de uso, extraídos de los requisitos
acordados con el cliente.

3. Tener definida una etapa de refactorización obliga a que el código escrito

sea revisado y mejorado siempre.

4. El código que se escribe se hace con el objetivo de pasar un test, y este

test ha sido escrito para comprobar un caso de uso, basado en un requisito
del cliente. Por lo que siempre es necesario.
 BDD
(Behavior Driven Development)
___________________________________________________
Mauricio Pérez Cárdenas
 BDD ¿Qué es?
___________________________________________________

Estrategia de desarrollo dirigido por comportamiento,

empatizando con el usuario final de tus desarrollos.

A diferencia de TDD, BDD se define en un idioma común

entre todos los stakeholders: Mejora la comunicación
entre equipos tecnológicos y no técnicos.
 BDD
Tanto en TDD como en BDD, las pruebas se deben
definir antes del desarrollo.
___________________________________________________

• En BDD las pruebas se centran en el usuario y el

comportamiento del sistema.
• En TDD las pruebas se centran en funcionalidades.
 BDD
___________________________________________________
te permite desarrollar, probar y pensar el código desde la perspectiva del
usuario.
 Características
___________________________________________________
Características
___________________________________________________

Todas las definiciones BDD se escriben en un idioma común.

El equipo describe los detalles de cómo se debe comportar la

aplicación a desarrollar, y de esta forma es comprensible por todos.

Hace posible que la colaboración entre los equipos técnicos y no

técnicos se ejecute con mayor eficiencia.
 Implementación
___________________________________________________
 Implementación
___________________________________________________

❖ Cada requisito debe convertirse en historias de usuario, defiendo

ejemplos concretos.

❖ Cada ejemplo debe ser un escenario de un usuario en el sistema.

❖ Ser consciente de la necesidad de definir "la especificación del

comportamiento de un usuario" en lugar de "la prueba unitaria
de una clase".
 Ventajas
___________________________________________________
 Ventajas
___________________________________________________
1. NO se definen 'pruebas', sino que se están definiendo
'comportamientos’.

2. Mejora la comunicación entre desarrolladores, testers, usuarios y la

dirección.

3. Debido a que BDD se específica utilizando un lenguaje simplificado y

común, la curva de aprendizaje es mucho más corta que TDD.

4. Como su naturaleza no es técnica, puede llegar a un público más

amplio.
Thank you very mucho…