PDF de programación - Diseño Agil con TDD

Dise˜no Agil con TDD

Carlos Bl´e Jurado y colaboradores.

Prologo de Jos´e Manuel Beas

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

2

´Indice general

I Base Te´orica

1. El Agilismo

1.1. Modelo en cascada . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
1.2. Hablemos de cifras
1.3. El manifiesto ´agil
. . . . . . . . . . . . . . . . . . . . . . .
1.4. ¿En qu´e consiste el agilismo?: Un enfoque pr´actico . . . . .
. . . . . . . . . . . . . . . . . . . . . .
1.5. La situaci´on actual
1.6. ´Agil parece, pl´atano es
. . . . . . . . . . . . . . . . . . . .
1.7. Los roles dentro del equipo . . . . . . . . . . . . . . . . . .
1.8. ¿Por qu´e nos cuesta comenzar a ser ´agiles? . . . . . . . . .

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

2.1. El algoritmo TDD . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Escribir la especificaci´on primero . . . . . . . . . . .
Implementar el c´odigo que hace funcionar el ejemplo
2.1.2.
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´on (ATDD)

3.1. Las historias de usuario . . . . . . . . . . . . . . . . . . . .
3.2. Qu´e y no C´omo . . . . . . . . . . . . . . . . . . . . . . . .
3.3. ¿Est´a hecho o no? . . . . . . . . . . . . . . . . . . . . . . .
3.4. El contexto es esencial
. . . . . . . . . . . . . . . . . . . .

31

33
35
37
38
40
44
46
47
49

53
56
56
57
58
60
60
60
61

63
64
68
70
71

3

´INDICE GENERAL

´INDICE GENERAL

4. Tipos de test y su importancia

4.1. Terminolog´ıa en la comunidad TDD . . . . . . . . . . . . .
4.1.1. Tests de Aceptaci´on . . . . . . . . . . . . . . . . . .
4.1.2. Tests Funcionales . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
4.1.3. Tests de Sistema
4.1.4. Tests Unitarios
. . . . . . . . . . . . . . . . . . . .
4.1.5. Tests de Integraci´on . . . . . . . . . . . . . . . . . .

5. Tests unitarios y frameworks xUnit

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

73
74
75
76
76
78
80

83
84

6. Mocks y otros dobles de prueba

95
6.1. Cu´ando usar un objeto real, un stub o un mock . . . . . . .
97
6.2. La met´afora Record/Replay . . . . . . . . . . . . . . . . . . 108

7. Dise˜no Orientado a Objetos

111
7.1. Dise˜no Orientado a Objetos (OOD)
. . . . . . . . . . . . . 111
7.2. Principios S.O.L.I.D . . . . . . . . . . . . . . . . . . . . . . 112
7.2.1. Single Responsibility Principle (SRP) . . . . . . . . . 113
7.2.2. Open-Closed Principle (OCP) . . . . . . . . . . . . . 113
7.2.3. Liskov Substitution Principle (LSP)
. . . . . . . . . 114
Interface Segregation Principle (ISP) . . . . . . . . . 114
7.2.4.
7.2.5. Dependency Inversi´on Principle (DIP)
. . . . . . . . 115
. . . . . . . . . . . . . . . . . . 116
Inversi´on del Control (IoC)

7.3.

II Ejercicios Pr´acticos

8. Inicio del proyecto - Test Unitarios

9. Continuaci´on del proyecto - Test Unitarios

119

121

157

10.Fin del proyecto - Test de Integraci´on

231
10.1. La frontera entre tests unitarios y tests de integraci´on . . . . 233
10.2. Dise˜no emergente con un ORM . . . . . . . . . . . . . . . . 243
. . . . . . . . . 246
10.3. La unificaci´on de las piezas del sistema . . . . . . . . . . . . 247

10.2.1. Dise˜nando relaciones entre modelos

11.La soluci´on en versi´on Python

12.Antipatrones y Errores comunes

249

289

4

´INDICE GENERAL

´INDICE GENERAL

A. Integraci´on Continua (CI)

297
A.1.
Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 297
A.2. Pr´acticas de integraci´on continua . . . . . . . . . . . . . . . 299
A.2.1. Automatizar la construcci´on . . . . . . . . . . . . . 299
A.2.2. Los test forman parte de la construcci´on . . . . . . . 300
A.2.3. Subir los cambios de manera frecuente . . . . . . . . 302
A.2.4. Construir en una m´aquina de integraci´on . . . . . . . 302
A.2.5. Todo el mundo puede ver lo que est´a pasando . . . . 303
A.2.6. Automatizar el despliegue . . . . . . . . . . . . . . . 304
A.3.
IC para reducir riesgos . . . . . . . . . . . . . . . . . . . . . 304
A.4. Conclusi´on . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

5

´INDICE GENERAL

´INDICE GENERAL

6

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

7

8

Pr´ologo

´Erase una vez que se era, un lejano pa´ıs donde viv´ıan dos cerditos, Pablo
y Adri´an que, adem´as, eran hermanos. Ambos eran los cerditos m´as listos
de la granja y, por eso, el gallo Iv´an (el gerente de la misma) organiz´o una
reuni´on en el establo, donde les encarg´o desarrollar un programa de ordenador
para controlar el almac´en de piensos. Les explic´o qu´e quer´ıa saber en todo
momento: cu´antos sacos de grano hab´ıa y qui´en met´ıa y sacaba sacos de
grano del almac´en. Para ello s´olo ten´ıan un mes pero les advirti´o que, en
una semana, quer´ıa ya ver algo funcionando. Al final de esa primera semana,
eliminar´ıa a uno de los dos.

Adri´an, que era el m´as joven e impulsivo, inmediatamente se puso manos
a la obra. “¡No hay tiempo que perder!”, dec´ıa. Y empez´o r´apidamente a
escribir l´ıneas y l´ıneas de c´odigo. Algunas eran de un reciente programa que
hab´ıa ayudado a escribir para la guarder´ıa de la vaca Paca. Adri´an pens´o que
no eran muy diferentes un almac´en de grano y una guarder´ıa. En el primero
se guardan sacos y en el segundo, peque˜nos 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´odigo comenz´o acor-

dando con Iv´an dos cosas: qu´e era exactamente lo que podr´ıa ver dentro de
una semana y c´omo sabr´ıa que, efectivamente, estaba terminada cada cosa.
Iv´an quer´ıa conocer, tan r´apido como fuera posible, cu´antos sacos de grano
hab´ıa en cada parte del almac´en porque sospechaba que, en algunas partes del
mismo, se estaban acumulando sacos sin control y se estaban estropeando.
Como los sacos entraban y sal´ıan constantemente, no pod´ıa saber cu´antos
hab´ıa y d´onde estaban en cada instante, as´ı que acordaron ir contabiliz´ando-
los por zonas y apuntando a qu´e parte iba o de qu´e 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´en.

9

Pr´ologo

Mientras Adri´an adelantaba a Pablo escribiendo muchas l´ıneas de c´odigo,
Pablo escrib´ıa primero las pruebas automatizadas. A Adri´an eso le parec´ıa
una p´erdida de tiempo. ¡S´olo ten´ıan una semana para convencer a Iv´an!

Al final de la primera semana, la demo de Adri´an fue espectacular, ten´ıa
un control de usuarios muy completo, hizo la demostraci´on desde un m´ovil y
ense˜n´o, adem´as, las posibilidades de un generador de informes muy potente
que hab´ıa desarrollado para otra granja anteriormente. Durante la demostra-
ci´on hubo dos o tres problemillas y tuvo que arrancar de nuevo el programa
pero, salvo eso, todo fue genial. La demostraci´on de Pablo fue mucho m´as
modesta, pero cumpli´o con las expectativas de Iv´an y el programa no fall´o en
ning´un momento. Claro, todo lo que ense˜n´o 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´odigo sin antes tener una prueba que le
indicara un error. Adri´an no pod´ıa creer que Pablo hubiera gastado m´as de la
mitad de su tiempo en aquellas pruebas que no hac´ıan m´as que retrasarle a
la hora de escribir las funcionalidades que hab´ıa pedido Iv´an. El programa de
Adri´an ten´ıa muchos botones y much´ısimas opciones, probablemente muchas
m´as de las que jam´as ser´ıan necesarias para lo que hab´ıa pedido Iv´an, pero
ten´ıa un aspecto “muy profesional”.

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

Adri´an, tan impulsivo y arrogante como siempre, no dud´o ni un instante.
“¡Trato hecho!”, dijo. Pablo explic´o que aceptar´ıa s´olo si Iv´an se compro-
met´ıa a colaborar como lo hab´ıa hecho durante la primera semana. A Iv´an le
pareci´o razonable y les convoc´o a ambos para que le ense˜naran el resultado
final en tres semanas.

Adri´an se march´o pitando y llam´o a su primo Sixto, que sab´ıa mucho
y le asegurar´ıa la victoria, aunque tuviera que darle parte de las ganancias.
Ambos se pusieron r´apidamente manos a la obra. Mientras Adri´an arreglaba
los defectillos encontrados durante la demo, Sixto se encarg´o de dise˜nar una
arquitectura que permitiera enviar mensajes desde el m´ovil hasta un webser-
vice que permit´ıa encolar cualquier operaci´on para ser procesada en paralelo
por varios servidores y as´ı garantizar que el sistema estar´ıa en disposici´on de
dar servicio 24 horas al d´ıa los 7 d´ıas de la semana.

10

Pr´ologo

Mientras tanto, Pablo se reuni´o con Iv´an y Bernardo (el encargado del
almac´en) para ver cu´ales deber´ıan ser las siguientes funcionalidades a desarro-
llar. Les pidi´o que le explicaran, para cada petici´on, qu´e beneficio obten´ıa la
granja con cada nueva fu