Qué son
Son tres formas de ordenar cómo programás. No compiten: cada una sirve en un momento distinto del trabajo.
- TDD (Test-Driven Development): escribís primero la prueba y después el código. Es una técnica que desarrolló Kent Beck a fines de los 90 como parte de Extreme Programming.
- SDD (Spec-Driven Development): escribís primero la especificación, un documento que dice cómo tiene que comportarse tu código. Esa especificación pasa a ser la fuente de verdad que usan tus herramientas y los agentes de IA para generar, probar y validar el código.
- ODD (Observability-Driven Development): programás pensando en cómo vas a ver qué pasa cuando tu app ya la usa gente de verdad. La planteó Charity Majors (Honeycomb) como un paso más allá de TDD: «TDD + Prod = ODD».
Comparación
| TDD | SDD | ODD | |
|---|---|---|---|
| Qué escribís primero | La prueba | La especificación | Lo que te deja ver qué hace tu app afuera |
| Cuándo | Mientras escribís el código | Antes de escribir el código | Cuando la app ya está en uso |
| Usala cuando | Algo no puede fallar, como la cuenta de un descuento | Le pedís a la IA algo grande, como una función nueva entera | Los errores aparecen solo afuera y nunca en tu compu |
| Analogía | La pregunta del examen antes de estudiar | El plano antes de construir la casa | El tablero del auto mientras manejás |
Cómo se hace TDD
El ciclo se resume como rojo, verde y refactorizar.
- Rojo. Escribís una prueba de lo que tiene que pasar. Todavía no hay código, así que falla.
- Verde. Escribís lo justo para que la prueba pase.
- Refactorizar. Ordenás el código sin cambiar lo que hace.
En la versión actual de Kent Beck (Canon TDD) convertís exactamente un ítem de tu lista en una prueba concreta que se pueda correr, y el refactor es opcional.
Cómo se hace SDD
Spec Kit de GitHub lo divide en cuatro fases:
- Especificar. Escribís qué tiene que hacer la función.
- Planear. Definís cómo se va a construir.
- Tareas. Partís el plan en tareas.
- Implementar. La IA escribe el código siguiendo la especificación.
Según GitHub, sirve sobre todo en proyectos nuevos y en funciones nuevas sobre sistemas que ya existen. Dentro de su proceso, Spec Kit exige TDD: toda la implementación tiene que seguir desarrollo guiado por pruebas.
Cómo se hace ODD
La observabilidad te deja entender un sistema desde afuera haciéndole preguntas. Se apoya en tres señales:
| Señal | Para qué |
|---|---|
| Registros (logs) | Ver qué pasó en cada momento |
| Métricas | Medir cómo se comporta la app |
| Trazas | Seguir el recorrido de una operación |
Las tres juntas: una tienda online
- SDD para el pago. Definís en la especificación qué tiene que hacer el pago.
- TDD para la cuenta. Probás que el total y el descuento den bien.
- ODD para producción. Ves si el pago falla con clientes reales.
No tenés que elegir una: usás cada una en su momento.
Si algo falla
- Si la IA escribe algo distinto de lo que querías, revisá la especificación: es la fuente de verdad que usa para generar el código.
- Si todo anda en tu compu pero falla con usuarios, sumá registros, métricas y trazas para poder ver qué pasa afuera.
- Si encontrás definiciones distintas de SDD, es normal: Thoughtworks dice que el término todavía está en evolución, y Spec Kit (GitHub), Kiro (AWS) y OpenSpec lo implementan cada uno a su manera.
- Si alguien te presenta ODD como un estándar cerrado, tené en cuenta que el nombre se discute, incluso dentro de Honeycomb.