1) El documento habla sobre las claves del Desarrollo Dirigido por Pruebas (TDD), incluyendo por qué usar TDD, cómo aplicar el proceso de TDD, y algunos desafíos de TDD. 2) El proceso de TDD implica escribir una prueba fallida, luego código mínimo para que pase, y refactorizar repetidamente. 3) Aunque TDD puede ser más lento, ayuda a evitar errores, mejorar el diseño y facilitar cambios en el código.

1. Las claves del
Desarrollo Dirigido por
Pruebas (o TDD)
javierj@us.es /
@IWT2_Javier

2. ¿Quién soy yo? - Blogs
Blogs: Proyectos:
JGraphT
HootboardGame

3. ¿Quién soy yo? - Proyectos
Congresos: Katas:

4. Índice
¿Por qué utilizar TDD?
¿Cómo aplicar TDD?
TDD’s Darkside

5. Índice
¿Por qué utilizar TDD?
¿Cómo aplicar TDD?
TDD Jam

6. • Sin pruebas
• No veía fácilmente el diseño
• Fallaba por sorpresa sin saber por qué
• Cambiaba por cambiar.
• Apechugar con las malas decisiones.
• No avanzaba.
• Presionado por fecha límite.
• Me sentía mal.
• Un cuadro típico de necesito TDD.
¿Por qué TDD?

7. Todo el software
miente
Cambia

8. Todos nos equivocamos
“No fracasé, sólo descubrí
999 maneras de como no
hacer una bombilla.”
Todo el software
miente
Cambia

9. ¿Por qué TDD?
NO

10. Probar los actores

11. ¿Qué es TDD?

12. ¿Qué es TDD?

13. ¿Qué es TDD?

14. ¿Qué es TDD?
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.

15. TDD no es probar
Desarrollador TDD Tester
Escribo una prueba con un observador Vale
Escribo una prueba con dos observadores Es lo mismo !!!!

16. Índice
¿Por qué utilizar TDD?
¿Cómo aplicar TDD?
TDD Jam

17. 2. El Proceso TDD
El proceso de TDD

18. 2. El Proceso TDD
¿Por qué?

19. Sobre escribir pruebas
• Assert first
• Pruebas
extremadamente
sencillas
• Prueba una única cosa
• Valores de entrada
concreto
• DRY: Don’r Repeat
Yourself

20. Sobre refactorizar
• Elimina el código
duplicado.
• Aumenta la
expresividad de tu
código.
• Sustituye
especificaciones por
detalles.
• Elimina malos olores.

21. Dirigir TDD

22. ¿A dónde me lleva TDD?
• Técnica Presentator-first, comienza .
• Domain-driven development / arquitectura
hexagonal / puertos y adaptadores
• No empieces por la base de datos.
• Objetos humildes que huyen de tu framework.
• Refactorizar a patrones de diseño
• GUIs anoréxicas.

23. TDD Roadmap
Continous integration

24. Herramientas

25. 25
TDD the Dark-Side

26. TDD en las trincheras
Every unit test you write is not production code
solving someone's problem.

27. TDD’s Darside
• ¿Y si no sabes lo que quieres?
• Resultados parciales
• Double-fest
• Ir poco a poco.
• Indirección.
• Constelación de clases.
• Desperdicio de pruebas
• TDD es más lento.

28. TDD is hot…. now

29. Índice
¿Por qué utilizar TDD?
¿Cómo aplicar TDD?
TDD Jam
Para terminar

30. Conclusiones
Pruébalo y elige

31. Te necesitamos

32. Extra
10.000 líneas de código C#...
Comprobado…. 124 assemblies .NET
generados…. Comprobado…. 52
scripts de construcción…
comprobado
Ahora que mis pruebas unitarias
están escritas puedo empezar a
construir mis componentes.

33. 33
Enlaces
• Blog: http://iwt2-javierj.tumblr.com/
• Libro:
http://www.iwt2.org/web/opencms/IWT2/comunid
ad/LibroTDD/?locale=es
• GameUS: http://www.gameus.es/
• IWT2 DojoUS:
http://www.iwt2.org/web/opencms/IWT2/comunid
ad/dojous/?locale=es
• Twitter: @IWT2_Javier/ @GameUsSev /
@TDDPractico
Fin