Este documento presenta una introducción al desarrollo dirigido por pruebas (TDD). Explica los tipos de pruebas, el flujo del proceso TDD, sus beneficios como mejor diseño de código y calidad, y desafíos como la fragilidad de las pruebas. También incluye referencias adicionales sobre TDD.

1. TDD - 101
Orlando Bustos Mateluna - 2017

2. Agenda
Tipos de Test
Definición / Flujos
¿Por Qué?
Beneficios / Costos
Principios
Ejemplo
Desafíos / Experiencias

3. Tipos de Test
Funcional
Unitarios
Mutación
Integración
Aceptación

4. Tipos de Test - Unitarios
• Prueba Unitaria
– Una prueba unitaria es una
forma de comprobar el
correcto funcionamiento de
una unidad de código.
• función
• procedimiento
• clase

5. Flujo Tradicional
Diseño
Test
Código
TRADICIONAL

6. TDD - Definición
• TDD son las siglas de Test Driven
Development, desarrollo dirigido por
pruebas.
• Proceso de desarrollo de software que se
basa en la idea de desarrollar pruebas,
codificar y refactorizar el código
construido.

7. TDD - Nuevo Flujo

8. T
D
D
F
l
u
j
o
Escribir un test
¿Pasó?
Escribir código Correr el test
¿Pasó?
Remover Errores
Refactorizar
Correr el test
¿Pasó?
Si
Si
Si
No
No
NoCorrer el test

9. TDD - ¿Por qué antes?
● De la manera tradicional las
pruebas suelen
estar condicionadas a lo
implementado, con lo que es
fácil obviar pruebas o olvidar
algunos casos de test.

10. TDD - ¿Por qué antes?
• Al realizar primero las pruebas se realiza
un ejercicio previo de análisis, de los requisitos y
de los diversos escenarios.

11. TDD - ¿Por qué antes?
– En mi experiencia, es fome, fome, fomisimo, hacer las pruebas
después de terminar el código.
– Como es tan aburrido, se hacen las pruebas mínimas para
poder escapar rápido de esa tarea.

12. TDD - ¿Por qué?
• TDD ayuda a producir diseños más simples y
menos acoplados.

13. TDD - ¿Por qué?
• TDD ayuda a crear un gran conjunto de pruebas
que dan "confianza" para realizar cambios o
incrementar la funcionalidad del sistema.

14. TDD - Costos
• Curva de aprendizaje pronunciada.
• El testing ralentiza el prototipado rápido.
• Los primeros sprints se suele entregar menos de
lo normal.

15. TDD - Beneficios
• Mejor cobertura de Test
• Mejor Diseño
• Solo funcionalidad requerida
• Ayuda a manejar el miedo de
cara a la complejidad
• Documentación de código
• Aumenta la calidad general

16. TDD - Beneficios
• Evidencia concreta de que tu
codigo funciona
• Acorta el tiempo de feedback
• Defectos después de deployar
son muy raros y poco críticos.

17. TDD - Principios

18. TDD - Principios (Reglas) - RED
No está permitido escribir código productivo sin tener una
prueba que falle.

19. TDD - Principios (Reglas) - RED
No está permitido escribir más código en una prueba, que el
necesario para que falle la misma.

20. TDD - Principios (Reglas) - GREEN
No está permitido escribir más código
productivo que el necesario para pasar su
prueba unitaria.
Babysteps.
Siguiendo patrones y buenas
prácticas.

21. TDD - Principios (Reglas) - REFACTOR
Eliminar duplicaciones y otros “code smells”.
– Hediondeces del código.

22. TDD - Code Smells
• Hediondeces de código comunes:
– Código duplicado
– Método grande
– Clase grande
– Demasiados parámetros
– Envidia de características
– Excesivo uso de literales

23. TDD - Ejemplo

24. TDD - Desafíos
● Las pruebas se tornan difíciles de escribir
○ por lo que sentimos una desaceleración importante.

25. TDD - Desafíos
● Son frágiles
○ por lo que cambios aparentemente sin importancia en el código
provocan que un montón de pruebas fallen.

26. TDD - Desafíos
● Mantenerlas en forma y funcionando se vuelve complejo y
consume tiempo.

27. TDD - Desafíos
● Finalmente nos damos por vencido y abandonamos
completamente nuestras mejores intenciones y pensamos
“Simplemente no vale la pena”.

28. Desafíos

29. TDD - Experiencias anteriores
• Copy-Paste
– Cuando se “copipastea” se tiende a olvidar TDD.

30. TDD - Experiencias anteriores
• Fragilidad
– Cualquier cambio en el código afecta las pruebas.

31. TDD - Experiencias anteriores
• Cobertura
– Desde el 1er
Commit tienes mínimo 80%.

32. TDD - Conclusión
• No es una bala de plata
“No existirá [en el horizonte de una década] un avance en tecnología o gestión, que por sí solo pueda
provocar una mejora en la productividad, fiabilidad y simplicidad en un orden de magnitud
[significativo/por diez] - Fred Brooks”

33. TDD - Conclusión
• Beneficios Comprobados
– (2008) - “TDD teams produced code that was 60 to
percent better in terms of defect density than non-T
teams.”

34. TDD - Conclusión
• Cambia la manera de pensar y trabajar
– Es complejo imaginar algunas pruebas a priori.

35. TDD - Conclusión
• Disciplina y Constancia
– Se requiere ser disciplinado y constante para no
abandonar en el peor momento de la curva de adopción.

36. TDD - Preguntas

37. TDD - Referencias
• Test driven development overview and adoption
– http://www.slideshare.net/pyxistech/test-driven-develop
ment-overview-and-adoption
• Comparative Study of Test Driven Development
with Traditional Techniques
– http://www.ijsce.org/attachments/File/v3i1/A1351033113
.pdf

38. TDD - Referencias
• TDD cómo y por qué, una guía para los no
iniciados
– http://artesanos.de/software/2012/02/13/tdd-como-y-po
rque-una-guia-para-los-no-iniciados/
• Introducción a TDD (Test Driven Development)
– http://blog.lordudun.es/2011/04/introduccion-a-tdd-test-
driven-development/

39. TDD - Referencias
• Conventional TDD is Sin!!
– http://agile.dzone.com/news/conventional-tdd-si
n
• 7th ANNUAL STATE of AGILE VERSIONONE®
Agile Made Easier DEVELOPMENT SURVEY
– http://www.versionone.com/pdf/7th-Annual-Stat
e-of-Agile-Development-Survey.pdf

40. TDD - Referencias
• Hediondez del Código
– http://es.wikipedia.org/wiki/Hediondez_del_c%C3%B3dig
o
• https://ryoshiga.com/category/tdd/
• https://www.slideshare.net/AtishNarlawar/td
d-in-agile

41. TDD - Referencias
• https://www.microsoft.com/en-us/research/blog/
exploding-software-engineering-myths/