Aprende TDD

Diseño Ágil con TDD
Carlos Blé Jurado y colaboradores.
Prologo de José Manuel Beas

Primera Edición, Enero de 2010
www.iExpertos.com
El libro se ha publicado bajo la Licencia Creative Commons

2

Índice general

I

Base Teórica

27

1. El Agilismo
1.1. Modelo en cascada . . . . . . . . . . . . . . . . . .
1.2. Hablemos de cifras . . . . . . . . . . . . . . . . . . .
1.3. Elmanifiesto ágil . . . . . . . . . . . . . . . . . . . .
1.4. ¿En qué consiste el agilismo?: Un enfoque práctico
1.5. La situación actual . . . . . . . . . . . . . . . . . . .
1.6. Ágil parece, plátano es . . . . . . . . . . . . . . . . .
1.7. Los roles dentro del equipo . . . . . . . . . . . . . .
1.8. ¿Por qué nos cuesta comenzar a ser ágiles? . . . .

.
.
.
.
.
.
.
.

.
.
.
..
.
.
.

.
.
.
.
.
.
.
.

28
30
32
33
36
40
42
43
46

2. ¿Qué es el Desarrollo Dirigido por Tests? (TDD)
48
2.1. El algoritmo TDD . . . . . . . . . . . . . . . . . . . . . . . 51
2.1.1. Escribir la especificación primero . . . . . . . . . . 52
2.1.2. Implementar el código que hace funcionar el ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.1.3.Refactorizar . . . . . . . . . . . . . . . . . . . . . . 53
2.2. Consideraciones y recomendaciones . . . . . . . . . . . . 55
2.2.1. Ventajas del desarrollador experto frente al junior . 55
2.2.2. TDD con una tecnología desconocida . . . . . . . 56
2.2.3. TDD en medio de un proyecto . . . . . . . . . . . 56
3. Desarrollo Dirigido por Tests de Aceptación (ATDD)
3.1. Las historias de usuario . . .. . . . . . . . . . . .
3.2. Qué y no Cómo . . . . . . . . . . . . . . . . . . . .
3.3. ¿Está hecho o no? . . . . . . . . . . . . . . . . . .
3.4. El contexto es esencial . . . . . . . . . . . . . . . .

3

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

58
59
63
66
67

ÍNDICE GENERAL

ÍNDICE GENERAL

4. Tipos de test y su importancia
4.1. Terminología en la comunidadTDD
4.1.1. Tests de Aceptación . . . . .
4.1.2. Tests Funcionales . . . . . .
4.1.3. Tests de Sistema . . . . . . .
4.1.4. Tests Unitarios . . . . . . . .
4.1.5. Tests de Integración . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
..
.
.
.
.
.

.
.
.
.
.
.

68
69
70
71
71
74
75

5. Tests unitarios y frameworks xUnit
77
5.1. Las tres partes del test: AAA . . . . . . . . . . . . . . . . 78
6. Mocks y otros dobles de prueba
88
6.1. Cuándo usar un objeto real, un stub o un mock . . . . . . 90
6.2. La metáfora Record/Replay . . . . . . . . . . . . . . . . . 101
7. Diseño Orientado a Objetos
7.1.Diseño Orientado a Objetos (OOD) . . . . . .
7.2. Principios S.O.L.I.D . . . . . . . . . . . . . .
7.2.1. Single Responsibility Principle (SRP)
7.2.2. Open-Closed Principle (OCP) . . . . .
7.2.3. Liskov Substitution Principle (LSP) . .
7.2.4. Interface Segregation Principle (ISP) .
7.2.5. Dependency Inversión Principle (DIP)
7.3. Inversión del Control (IoC) . . . . . . . . . . .

II

.
.
..
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

Ejercicios Prácticos

104
104
105
106
107
107
108
108
109

111

8. Inicio del proyecto - Test Unitarios

112

9. Continuación del proyecto - Test Unitarios

148

10. Fin del proyecto - Test deIntegración
10.1.La frontera entre tests unitarios y tests de integración
10.2.Diseño emergente con un ORM . . . . . . . . . . . . .
10.2.1. Diseñando relaciones entre modelos . . . . . .
10.3.La unificación de las piezas del sistema . . . . . . . .

222
224
235
237
238

.
.
.
.

.
.
.
.

11. La solución en versión Python

240

12. Antipatrones y Errores comunes

281

4...