Desarrolla sin miedo con TDD
Aprende a escribir código que no se rompa, paso a paso
Escribes la funcionalidad, la pruebas manualmente, parece que funciona. La despliegas. Dos días después hay un bug que no habías previsto. Tienes que volver, entender qué pasó, arreglarlo, volver a probar manualmente. Y mientras tanto, añadir algo nuevo al código que ya existe se vuelve arriesgado porque no sabes qué puede romperse.
El problema no es falta de habilidad. Es que programar sin tests es programar sin retroalimentación. Cada error que no detectas al escribir el código, lo detectas más tarde y en un peor momento.
TDD invierte ese ciclo. Pero para que funcione, necesitas saber exactamente cómo funciona el proceso. Y eso es lo que enseña este curso.
Aplicar el ciclo Red-Green-Refactor sin bloquearte en cada paso
Saber qué test escribir primero y cómo avanzar de forma incremental
Escribir código más simple porque los tests te fuerzan a simplificarlo
Adoptar prácticas que te ayudarán a crear soluciones más robustas y sostenibles.
Menos tiempo debuggeando problemas que podrías haber detectado al escribir el código
Cambios y refactorizaciones con más seguridad, porque tienes una red que te avisa si algo se rompe
Despliegues con menos ansiedad, porque sabes lo que el código hace y lo que no
Decisiones técnicas más confiadas, respaldadas por evidencia en lugar de intuición
✅ Eres developer y has intentado TDD pero te has bloqueado o lo has abandonado
✅ Estás cansado de bugs recurrentes y de dedicar tiempo a debugging que podría evitarse
✅ Quieres entender TDD de verdad, no solo leer sobre él
✅ Estás en un nivel junior avanzado o mid-level y quieres una base sólida de testing
❌ Ya aplicas TDD de forma fluida en proyectos reales y buscas técnicas avanzadas
❌ Buscas teoría sin ejercicios: este curso requiere practicar
❌ No programas activamente en proyectos reales o personales
❌ Esperas aprender TDD sin cambiar la forma en que trabajas
Test-driven development (TDD) como técnica de diseño y desarrollo incremental
Beneficios de usar Test-driven development
¿Cuando es recomendable y cuando no usar TDD?
Para que TDD funcione hay que practicar mucho
BONUS: 7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development
Las 3 leyes del TDD
Ejemplo: Greeting Kata (1 de 2)
Tres métodos para avanzar de rojo a verde
Ejemplo: Greeting Kata (2 de 2)
Ejercicio: Fizz Buzz Kata
Solución: Fizz Buzz Kata (1 de 3)
Refactorizar y la regla del 3
Solución: Fizz Buzz Kata (2 de 3)
Solución: Fizz Buzz Kata (3 de 3)
Ejercicio: Leap Year Kata
Ejercicio: Leap Year Kata (tarea)
Solución: Leap Year Kata
Bonus: Solución a Fizz Buzz Kata con TypeScript y Jest
Cuestionario de evaluación
Introducción a los hábitos con TDD
Emplea una checklist para saber qué te falta
Trata los tests como especificaciones
Organizar el test en bloques Given/When/Then
Comienza por el then y escribe hacia atrás
Intenta adivinar el resultado del test antes de lanzarlo
Los tests son código de primera clase
¿Test rígidos? Considera cambiar el diseño
Kata: String Calculator
Kata: String Calculator (tarea)
Kata: Anagramas (con Baby Steps)
Cuestionario de evaluación
¡Sigue practicando! Guía para la práctica deliberada con katas
Recursos adicionales
Antes de que te vayas...
Al principio sí. Como cualquier habilidad nueva. Pero un developer que trabaja con TDD detecta errores antes, refactoriza con más seguridad y dedica menos tiempo a debuggear. El coste de aprender TDD se recupera rápido. El coste de no aprenderlo se acumula en bugs, en tiempo de QA y en código que nadie quiere tocar.
Si escribes código, aplica. Las katas de este curso son ejercicios simples precisamente para que puedas centrarte en el proceso. Una vez que tienes el ritmo claro, puedes aplicarlo en el trabajo real.
La razón más común por la que TDD no funciona al intentarlo solo es no saber qué hacer en cada paso. Este curso es exactamente eso: una guía paso a paso del proceso, con los puntos de bloqueo explicados.
El curso dura aproximadamente dos horas. Es una inversión pequeña para un cambio de forma de trabajar que tiene impacto directo en la calidad del código y en el tiempo que dedicas a resolver problemas que podrías haber prevenido.