Test Driven Development

Uzi Mamani Creative Commons (@uzigula)
Test Driven Development
Uzi Mamani
uzi.mamani@gmail.com
www.about.me/uzigula

2Uzi Mamani Creative Commons (@uzigula)
“I don’t have time to write
tests because I am too busy
debugging.”

3
¿Qué es Test Driven Development?
«TDD es escribir las pruebas
primero y dejar que estas
guíen o modifiquen el diseño»

Dada la definición de TDD
¿Qué necesita usted para ponerlo en práctica?

Historias de Usuario
➢ Descripción : Un relato resumido que debe reflejar el que se
debe construir y por que.
➢ Conversaciones: Son los detalles que hay detrás de la
Historia, estas se generan durante las conversaciones con
por ejemplo el Product Owner.
➢ Validación : Criterios de Aceptación que permitan validar si
la Historia fue correctamente desarrollada.

Ejemplo: Sitio Web de Viajes
6
Como un usuario, Deseo poder
reservar una habitación de Hotel
Como un usuario, Deseo poder
cancelar una reservación
Como un planificador de
Vacaciones, Deseo ver fotos de
los hoteles.
Como pasajero frecuente,
Deseo poder reutilizar una
reserva pasada, para así ahorrar
tiempo en mis reservas.

Criterios de Aceptación
7
Como un usuario, Deseo
poder cancelar una
reservación
✓ Un Miembro premium puede
cancelar una reserva el ultimo día
sin recargo.
✓ Un miembro no-premium se le
cobrará 10% si cancela el mismo
día de la reserva.
✓ Se debe enviar un Correo de
Confirmación.
✓ Se debe Notificar al Hotel de la
cancelación.

Test de Aceptación
Dado Juan usuario no-premium
Y Con una reserva para Hoy a las 19:00 con un valor s/. 500
Cuando Cancela la reserva
Entonces la reserva es cancelada
Y Juan debe pagar una penalidad de S/. 50.
(Ejemplo concreto)

Ciclo de Test Driven Development
9
RED
Refact
or
Green

Kata : Stack
Se nos pide implementar un Pila.
1. La pila esta llena cuando se llega al total de elementos.
2. La pila es una estructura (LIFO – Last In First Out), por tanto
siempre se debe sacar el ultimo elemento ingresado a la pila
siempre cuando no este vacia.

Pirámide de Testing

¿Que es una prueba Unitaria?
Es una pieza de código automatizada, que invoca el método o
clase que está siendo testeada y verifica algunas asunciones
acerca del comportamiento lógico de dicho método o clase.
Generalmente escrito usando un framework de pruebas
unitarias, se ejecuta rápidamente, es completamente
automatizable, confiable, legible y mantenible.

Como funciona un Test Unitario
13
Take it from The Art Of Unit Testing – Roy Osherove
2009

Ejemplo de Prueba Unitaria
14
@Test
public void IsValidFileName_validFile_ReturnsTrue()
{
//arrange
LogAnalyzer analyzer = new LogAnalyzer();
//act
bool result = analyzer.IsValidLogFileName("whatever.doc");
//assert
assertTrue(result, "filename should be valid!");
}

Características de las Pruebas Unitarias
✓ Fast
✓ Isolated
✓ Repetible
✓ Self-Verifying
✓ Timely

Buenas prácticas de Pruebas Unitarias
16
1. Consistentes
2. Atómicos
3. Simple Responsabilidad
4. Auto Descriptivos
5. Los test no deben tener lógica

Buenas prácticas de Pruebas Unitarias
17
6. No manejan excepciones
7. Mensajes Claros
8. No mezclar el código
9. Separación por capa de negocio
10. Separación por tipo

Tres Leyes de Test Driven Development
1. You are not allowed to write any production code unless it
is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is
sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code
than is sufficient to pass the one failing unit test.
18http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTddUzi Mamani Creative Commons (@uzigula)

Kata Login Api
Api de Autenticación
Como SysAdmin deseo un servicio que resuelva la
autenticación/autorización de un usuario a una determinada
aplicación, para así tener un único servicio de control de
acceso.

Kata Login Api
Confirmación:
1. Acceso Autorizado
• Usuario y contraseña son válidos.
• Devolver un Response con el token de Autorización.
2. Acceso Denegado
• Usuario y/o contraseña no son válidos.
• Cuenta esta bloqueada.
• No tiene permisos para la aplicación solicitada.
• Servicio no esta disponible (falla infraestrutura)

Enfoques para aplicar TDD en un
Desarrollo

Outside-In
Se comienza con una clase o componente de alto nivel, se
mockean las dependencias necesarias. Cuando se ha finalizado
con el componente, nos movemos al colaborador previamente
mockeado y aplicamos TDD nuevamente ahí.
22
Mock
Collaborator
Collaborator
Class
User
Controller
Outer
Class
Model
System
Boundary
In
Out

Outside-In
Beneficios
• Permite pensar desde la perspectiva del usuario final, el
diseño está guiado por necesidades reales.
• Se construye incrementalmente partes completas de la
aplicación.
Desventajas
• Puede llevar al uso excesivo de mocks/stubs ocasionando
que las pruebas sean muy frágiles.

Inside-Out
Comienza con una clase o componente de bajo nivel y se va
progresando a los de más alto nivel.
No utiliza mocking, debido a que los colaboradores son
previamente creados o se devuelven valores en duro.
24
Collaborator
Class
Collaborator
Class
User
Controller
Outer
Class
Model
System
Boundary
In
Out

Inside-Out
Beneficios
• Tiende a tener un mejor diseño.
Desventajas
• Puedes construir funcionalidad en las clases que nunca será
usada por la aplicación.

Test Doubles e Isolation (Mock)
Frameworks

Test Doubles
«Son todos aquellos objetos que
son creados para reemplazar a los
objetos reales con el propósito de
hacer pruebas »

Isolation Mocking Frameworks
• Permiten crear test doubles de manera más simple, rápida y
sin errores.
• Ayudan a evitar escribir código repetitivo.
▪ .NET: Moq, RhinoMock, Typemock , Nsubstitute
▪ Java: Mockito, EasyMock, Jmock
▪ Ruby: RSpec Built-in, Mocha

Test Doubles Stubs
• Reemplaza una dependencia existente en el sistema de tal
manera que el test no tenga que lidiar directamente con esa
dependencia.
• La prueba tiene el control sobre este test double, por lo que
puede indicarle respuestas predefinidas a ciertas llamadas.
• Son utilizados cuando nuestro método en prueba depende de
un valor que es retornado por otro componente.

State Testing Vs Interaction Testing
State Testing (Result Driven)
Verificamos si un resultado final es el esperado.
Ejm: que una propiedad ha cambiado su valor.
Interaction Testing (Action Driven)
Verificamos si una determinada acción se ha producido.
Ejm: que se ha enviado un mensaje hacia otro objeto.

Test Doubles Mocks
• No devuelve resultados predefinidos, sino está pendiente que
2 objetos hayan interactuado de manera esperada.
• El Assert ya no se ejecuta sobre la clase en prueba sino sobre
el mock.
• Lo usamos para probar acciones que no pueden ser
observadas a través de la API pública de la clase que se está
probando.

Kata:
Login API , nuevo requerimiento

Kata: Login Api (Nuevo requerimiento)
Se requiere implementar en el API de Autorizacion una opción
que permita resetear el password de un usuario registrado.

Como diferenciamos Stubs de Mocks
✓ Un Stub permite que el test pueda terminar su ejecución.
(No falle)
✓ Un Mock es un test double sobre el cuál se realiza la
verificacion (aserción)

Otros Test Doubles
Dummy:
Objetos que se encuentran instanciados pero nunca se utilizan,
usualmente usados para llenar una lista de parámetros
Fake :
Remplazan a la dependencia real por razones diferentes a
verificar salidas o comportamientos. Tienen la misma
funcionalidad pero más sencilla

Kata:
Simulador de Créditos

Simulador de Calendario de Pagos.
Como sectorista deseo poder obtener el reporte de simulador
de crédito de una solicitud, para así poder mostrar al cliente su
posible calendario de pagos.
La solicitud debe tener Monto Solicitado, Plazo en Meses,
Interés.
Considerar que pueden haber múltiples formas de calcular el
valor de una cuota
Por ahora las cuotas deberán ser calculadas usando Interés
simple

Kata:
Tratemos con algo de
Tu Proyecto

39
Don’t be a Cowboy

Test Driven Development

Más contenido relacionado

Destacado (10)

Similar a Test Driven Development (20)

Más de Uzi Mamani Fernández (10)

Último (20)

Test Driven Development