El documento presenta una introducción al Desarrollo Guiado por Pruebas (TDD) a través de la experiencia personal del autor, quien detalla sus objetivos, recomendaciones y resultados obtenidos al aplicar esta metodología. Se discuten los elementos y ciclo de un test, así como los desafíos y consideraciones al implementarlo en proyectos de software. Además, se plantean preguntas sobre la viabilidad y la efectividad de TDD en diferentes contextos de desarrollo.

1. TDD desde las trincheras
Leonardo Micheloni
@leomicheloni

2. @leomicheloni

3. ¿Quién soy?
• Leonardo Micheloni
• +15 Programador
• +10 años en Agile
• Tokiota
@leomicheloni
@leomicheloni

4. Objetivo
• Comprender TDD
• Contar experiencias
• No “vender” la idea
@leomicheloni

5. ¿Qué es TDD?
• Desarrollar a partir de los test
• Escribir primero el test, luego el código que valida el test
• Comenzar from scratch
• Crear la versión más simple del código que haga pasar el test
• Refactorizar
• Baby steps
@leomicheloni

6. Estructura de un test
• Setup
• Ejecución
• Validación
• Cleanup
@leomicheloni

7. Simples
@leomicheloni

8. TDD ciclo
@leomicheloni

9. Terminología
• Dummy
• Solo datos
• Stub
• Datos condicionales
• Mock
• Comportamiento
@leomicheloni

10. Mock
@leomicheloni

11. Algunas recomendaciones
• Keep unit small
• Reducir el debugging
• Si hay un bug, hacer un test
• El código queda “autodocumentado”
@leomicheloni

12. ¿Qué permite TDD?
• Comenzar sin depender de otros componentes
• Mejorar la comprensión del negocio (fail fast)
• Descubrir la API
• Trabajar por iteraciones (pomodoro)
• Que emerja la arquitectura
• Detectar casos de uso
@leomicheloni

13. Qué requiere?
• Ciertos conocimientos “avanzado” (como IoC)
• Disciplina
• Capacidad para separar el problema
@leomicheloni

14. Resultado
• Pensar la solución a partir del uso
• Mayor confianza en lo entregado
• Mayor felicidad
• Mayor calidad (refactor)
• Evita el sobre-diseño
• Evolución sólida => test
@leomicheloni

15. Live coding
@leomicheloni

16. Experiencias
• Proyectos legacy (funcionalidades nuevas)
• Difícil comenzar desde cero
• Hace falta práctica
• No vale la pena en todo el código (code coverage)
• Hace falta experiencia
• Es necesario conocer ciertas herramientas
• No es simple aplicarlo a todas las áreas (UI, etc.)
• Puede dar una falsa sensación de seguridad
@leomicheloni

17. Grandes preguntas
• ¿Se puede hacer siempre TDD?
• ¿Cualquiera puede hacer TDD?
• ¿Se puede aplicar en toda la aplicación?
• ¿Queda el código “autodocumentado”?
• ¿La aplicación es más confiable?
• ¿Aumenta el costo de mantenimiento?
• ¿Se puede aplicar en proyectos existentes?
@leomicheloni

18. Preguntas
@leomicheloni

19. Gracias! @leomicheloni
@leomicheloni

20. Links útiles
• TDD Katas: http://osherove.com/tdd-kata-1/
• Fizz Buzz Kata: https://opencredo.com/blogs/tdd-fizzbuzz-junit-
theories/
• Bob Martin: https://blog.cleancoder.com/
• TDD Wars: https://www.codewars.com/
• Mi canal de Youtube:
https://www.youtube.com/channel/UCQlqd6byJpXtGuYrL4cElgw
• Mi blog: http://leomicheloni.com
@leomicheloni