PDF de programación - Diseño Ágil con 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

1. El Agilismo

1.1. Modelo en cascada . . . . . . . . . . . . . . . . . . . . .
1.2. Hablemos de cifras . . . . . . . . . . . . . . . . . . . . . .
1.3. El manifiesto á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? . . . . . . .

2. ¿Qué es el Desarrollo Dirigido por Tests? (TDD)

2.1. El algoritmo TDD . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Escribir la especificación primero . . . . . . . . . .
Implementar el código que hace funcionar el ejem-
2.1.2.
plo . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3. Refactorizar . . . . . . . . . . . . . . . . . . . . . .
2.2. Consideraciones y recomendaciones . . . . . . . . . . . .
2.2.1. Ventajas del desarrollador experto frente al junior .
2.2.2. TDD con una tecnología desconocida . . . . . . .
2.2.3. TDD en medio de un proyecto . . . . . . . . . . .

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 . . . . . . . . . . . . . . . . . . . .

27

28
30
32
33
36
40
42
43
46

48
51
52

52
53
55
55
56
56

58
59
63
66
67

3

ÍNDICEGENERAL

ÍNDICEGENERAL

4. Tipos de test y su importancia

4.1. Terminología en la comunidad TDD . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . .

5. Tests unitarios y frameworks xUnit

5.1. Las tres partes del test: AAA . . . . . . . . . . . . . . . .

68
69
70
71
71
74
75

77
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

104
7.1. Diseño Orientado a Objetos (OOD) . . . . . . . . . . . . . 104
7.2. Principios S.O.L.I.D . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . 106
7.2.1. Single Responsibility Principle (SRP)
7.2.2. Open-Closed Principle (OCP) . . . . . . . . . . . . 107
7.2.3. Liskov Substitution Principle (LSP) . . . . . . . . . 107
Interface Segregation Principle (ISP) . . . . . . . . 108
7.2.4.
7.2.5. Dependency Inversión Principle (DIP)
. . . . . . . 108
Inversión del Control (IoC) . . . . . . . . . . . . . . . . . . 109

7.3.

II Ejercicios Prácticos

8.

Inicio del proyecto - Test Unitarios

9. Continuación del proyecto - Test Unitarios

111

112

148

10. Fin del proyecto - Test de Integración

222
10.1.La frontera entre tests unitarios y tests de integración . . 224
10.2.Diseño emergente con un ORM . . . . . . . . . . . . . . . 235
10.2.1. Diseñando relaciones entre modelos . . . . . . . . 237
10.3.La unificación de las piezas del sistema . . . . . . . . . . 238

11. La solución en versión Python

12. Antipatrones y Errores comunes

240

281

4

ÍNDICEGENERAL

ÍNDICEGENERAL

A. Integración Continua (CI)

288
A.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . 288
A.2. Prácticas de integración continua . . . . . . . . . . . . . . 291
A.2.1. Automatizar la construcción . . . . . . . . . . . . . 291
A.2.2. Los test forman parte de la construcción . . . . . . 292
A.2.3. Subir los cambios de manera frecuente . . . . . . 293
A.2.4. Construir en una máquina de integración . . . . . 294
A.2.5. Todo el mundo puede ver lo que está pasando . . 294
A.2.6. Automatizar el despliegue . . . . . . . . . . . . . . 295
A.3. IC para reducir riesgos . . . . . . . . . . . . . . . . . . . . 296
A.4. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . 297

5

A la memoria de nuestro querido gatito Lito, que vivió con total
atención y entrega cada instante de su vida

6

Prólogo

Érase una vez que se era, un lejano país donde vivían dos cerditos,
Pablo y Adrián que, además, eran hermanos. Ambos eran los cerditos
más listos de la granja y, por eso, el gallo Iván (el gerente de la mis-
ma) organizó una reunión en el establo, donde les encargó desarrollar
un programa de ordenador para controlar el almacén de piensos. Les
explicó qué quería saber en todo momento: cuántos sacos de grano
había y quién metía y sacaba sacos de grano del almacén. Para ello
sólo tenían un mes pero les advirtió que, en una semana, quería ya ver
algo funcionando. Al final de esa primera semana, eliminaría a uno de
los dos.

Adrián, que era el más joven e impulsivo, inmediatamente se puso
manos a la obra. “¡No hay tiempo que perder!”, decía. Y empezó rápida-
mente a escribir líneas y líneas de código. Algunas eran de un reciente
programa que había ayudado a escribir para la guardería de la vaca
Paca. Adrián pensó que no eran muy diferentes un almacén de grano
y una guardería. En el primero se guardan sacos y en el segundo, pe-
queños animalitos. De acuerdo, tenía que retocar algunas cosillas para
que aquello le sirviera pero bueno, esto del software va de reutilizar lo
que ya funciona, ¿no?

Pablo, sin embargo, antes de escribir una sola línea de código co-
menzó acordando con Iván dos cosas: qué era exactamente lo que
podría ver dentro de una semana y cómo sabría que, efectivamente,
estaba terminada cada cosa. Iván quería conocer, tan rápido como fue-
ra posible, cuántos sacos de grano había en cada parte del almacén
porque sospechaba que, en algunas partes del mismo, se estaban acu-
mulando sacos sin control y se estaban estropeando. Como los sacos
entraban y salían constantemente, no podía saber cuántos había y dón-
de estaban en cada instante, así que acordaron ir contabilizándolos por

7

Prólogo

zonas y apuntando a qué parte iba o de qué parte venía, cada vez que
entrara o saliera un saco. Así, en poco tiempo podrían tener una idea
clara del uso que se estaba dando a las distintas zonas del almacén.

Mientras Adrián adelantaba a Pablo escribiendo muchas líneas de
código, Pablo escribía primero las pruebas automatizadas. A Adrián eso
le parecía una pérdida de tiempo. ¡Sólo tenían una semana para con-
vencer a Iván!

Al final de la primera semana, la demo de Adrián fue espectacu-
lar, tenía un control de usuarios muy completo, hizo la demostración
desde un móvil y enseñó, además, las posibilidades de un generador
de informes muy potente que había desarrollado para otra granja ante-
riormente. Durante la demostración hubo dos o tres problemillas y tuvo
que arrancar de nuevo el programa pero, salvo eso, todo fue genial. La
demostración de Pablo fue mucho más modesta, pero cumplió con las
expectativas de Iván y el programa no falló en ningún momento. Claro,
todo lo que enseñó lo había probado muchísimas veces antes gracias a
que había automatizado las pruebas. Pablo hacía TDD, es decir, nunca
escribía una línea de código sin antes tener una prueba que le indicara
un error. Adrián no podía creer que Pablo hubiera gastado más de la
mitad de su tiempo en aquellas pruebas que no hacían más que retra-
sarle a la hora de escribir las funcionalidades que había pedido Iván.
El programa de Adrián tenía muchos botones y muchísimas opciones,
probablemente muchas más de las que jamás serían necesarias para
lo que había pedido Iván, pero tenía un aspecto “muy profesional”.

Iván no supo qué hacer. La propuesta de Pablo era muy robusta y
hacía justo lo que habían acordado. La propuesta de Adrián tenía cosi-
llas que pulir, pero era muy prometedora. ¡Había hecho la demostración
desde un móvil! Así que les propuso el siguiente trato: “Os pagaré un
50 % más de lo que inicialmente habíamos presupuestado, pero sólo
a aquel de los dos que me haga el mejor proyecto. Al otro no le daré
nada.”. Era una oferta complicada porque, por un lado, el que ganaba
se llevaba mucho más de lo previsto. Muy tentador. Pero, por el otro la-
do, corrían el riesgo de trabajar durante un mes completamente gratis.
Mmmmm.

Adrián, tan impulsivo y arrogante como siempre, no dudó ni un ins-
tante. “¡Trato hecho!”, dijo. Pablo explicó que aceptaría sólo si Iván se
comprometía a colaborar como lo había hecho durante la primera se-
mana. A Iván le pareció razonable y les convocó a ambos para que le
enseñaran el resultado final en tres semanas.

Adrián se marchó pitando y llamó a su primo Sixto, que sabía mucho
y le aseguraría la victoria, aunque tuviera que darle parte de las ganan-

8

Prólogo

cias. Ambos se pusieron rápidamente manos a la obra. Mientras Adrián
arreglaba los defectillos encontrados durante la demo, Sixto se encar-
gó de diseñar una arquitectura que permitiera enviar mensajes desde
el móvil hasta un webservice que permitía encolar cualquier operación
para ser procesada en paralelo por varios servidores y así garantizar
que el sistema estaría en disposición de dar servicio 24 horas al día los
7 días de la semana.

Mientras tanto, Pablo se reunió con Iván y Bernardo (el encargado
del almacén) para ver cuáles deberían ser las siguientes funcionalida-
des a desarrollar. Les pidió que le explicaran, para cada petición, qué
beneficio obtenía la granja con cada nueva funcionalidad. Y así, poco
a poco, fueron elaborando una lista de funcionalidades priorizadas y
resumidas en una serie de tarjetas. A continuación, Pablo fue, tarjeta
a tarjeta, discutiendo con Iván y Bernardo cuánto tiempo podría tardar
en terminarlas. De paso, aprovechó para anotar a