El documento presenta las claves del desarrollo dirigido por pruebas (TDD), enfatizando su importancia para evitar problemas comunes en el desarrollo de software e introducir mejoras significativas. Se explican los principios básicos de TDD, así como las buenas prácticas a seguir, como iniciar con ejemplos sencillos y utilizar pruebas como código de primera. Además, se menciona que TDD requiere disciplina y puede generar falsas sensaciones de velocidad y seguridad si no se aplica correctamente.

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

2. ¿Quién soy yo?

3. Índice

4. ¿Por qué TDD?
• 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.

5. ¿Qué es TDD?

6. ¿Qué es TDD?

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

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

9. Puntos clave de TDD
•
•
•
•
•
•
Pruebas sencillas
¿Por dónde empezamos?
Babysteps
De abajo a arriba.
Usa papel y lápiz.
Prepara tu código para el
cambio.
• Pruebas son código de
primera.

10. Pruebas Sencillas
Don't let yourself get
attached to anything you
are not willing to walk out
on in 30 seconds flat if you
feel the heat around the
corner.

11. Prueba son código de primera

12. Prueba son código de primera

13. Babysteps

14. Empieza por el ejemplo más sencillo

15. Empieza por el ejemplo más sencillo
Librería de fracciones

16. Prepárate para el cambio

17. Prepárate para el cambio

18. Usa siempre lápiz y papel

19. Buenas prácticas en TDD
Diario de diseño.

20. De abajo a arriba

21. De abajo a arriba
Do the double

22. TDD desde las trincheras

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

24. Trincheras. Bases de Datos

25. Trincheras. Bases de Datos
Código de
negocio
Dobles de
prueba
Código de
acceso a la
BBDD
BBDD
Análisis de SQL
BBDD en
memoria

26. Trincheras. Desarrollo para Android

27. Trincheras. Videojuegos.
NO

28. Conclusiones
Pruébalo y elige

29. Conclusiones
TDD requiere disciplina
• Falsa sensación de
velocidad.
• Falsa sensación de
seguridad.
• No tener claro qué probar
• Set-up complejo.
• Módulos “Dios”

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

31. Extra
31

32. Agradecimientos
Onikami

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
33