Qué puede demostrar el desarrollo guiado por pruebas y qué no

El desarrollo guiado por pruebas (TDD) desarrolla software mediante ciclos cortos de feedback. Un desarrollador escribe una prueba para el siguiente comportamiento, observa que falla, implementa el código suficiente para aprobarla y refactoriza mientras la suite sigue en verde. El método puede hacer visibles pronto las suposiciones y el comportamiento esperado. No elimina los defectos ni sustituye los demás controles de un sistema de producción.

Qué promete realmente el ciclo TDD

Martin Fowler describe el ciclo central así: escribir una prueba para la siguiente funcionalidad, escribir código funcional hasta que pase y refactorizarlo hacia una estructura más clara. Los equipos lo resumen como rojo, verde y refactorización. La prueba debe fallar primero por una razón significativa. Si no, un resultado verde puede indicar solo que nunca ejercitó el comportamiento previsto.

TDD ofrece disciplina de desarrollo, no una garantía de cobertura. Un desarrollador puede omitir un escenario importante, afirmar el resultado equivocado, simular una integración arriesgada o preservar perfectamente un requisito defectuoso. La afirmación útil es más estrecha: el comportamiento representado por una prueba significativa puede recibir feedback rápido de regresión cuando la suite funciona de forma fiable.

La famosa polilla no originó la palabra

En 1947, ingenieros que trabajaban con el Harvard Mark II encontraron una polilla en un componente y la pegaron en su libro de registro con la nota «first actual case of bug being found». Grace Hopper estaba entre quienes trabajaban con el equipo del Mark II. El episodio popularizó los términos informáticos «bug» y «debug», pero no creó la palabra «bug». El libro conservado no se atribuye con certeza a Hopper personalmente.

El incidente de la polilla del Mark II se registró en 1947.

Dónde puede ayudar TDD

TDD resulta especialmente útil cuando un equipo puede expresar el comportamiento con ejemplos pequeños y deterministas. Puede aclarar interfaces, revelar acoplamiento incómodo, facilitar refactorizaciones seguras y mantener bajo revisión automatizada comportamientos ya corregidos. También aporta material concreto para revisar código: se comparan el comportamiento declarado, la implementación y los límites que la prueba no cubre.

El resultado económico depende del contexto. TDD exige esfuerzo de diseño y mantenimiento, y una suite frágil o lenta puede convertirse en un coste de entrega. El ahorro depende del riesgo de defectos, frecuencia de cambio, vida del sistema, alcance, velocidad del feedback y coste del fallo. Un caso de negocio responsable mide defectos escapados, lead time, pruebas inestables, duración, mantenimiento y recuperación en vez de prometer un ahorro universal.

"Usa pruebas para convertir suposiciones importantes en algo ejecutable y verifica después los riesgos que esas pruebas no pueden cubrir."

Por qué aprobar pruebas no demuestra corrección

Una suite evalúa entradas seleccionadas y resultados esperados. Por sí sola no puede demostrar la ausencia de defectos. Puede omitir fallos de concurrencia, datos externos malformados, comportamiento de dependencias, brechas de autorización, configuración de producción o una regla de negocio incorrecta. Los porcentajes de cobertura también requieren interpretación: ejecutar una línea no demuestra que se probaron todas las transiciones o invariantes importantes.

Elige técnicas según el riesgo. Las pruebas unitarias sirven para comportamiento local. Las pruebas de contrato e integración cubren límites entre componentes. Las pruebas basadas en propiedades y el fuzzing exploran entradas no enumeradas manualmente. El análisis estático encuentra clases de debilidades sin ejecutar el programa. Revisiones, modelado de amenazas, pruebas de penetración, monitorización y ejercicios de incidentes cubren otras partes.

Qué cambia para los smart contracts

Los smart contracts pueden controlar activos valiosos, exponer puntos públicos, componerse con contratos externos y operar bajo reglas del protocolo. Eso eleva el coste de errores de autorización, contabilidad, oráculos, upgrades o diseño económico. No convierte TDD en un método de seguridad completo.

Para sistemas EVM, un plan de verificación puede combinar pruebas unitarias con invariantes o propiedades, fuzzing, análisis estático, integración sobre redes bifurcadas, revisión de acceso, comprobaciones de compilador y dependencias, y evaluación manual de lógica y ataques económicos. Frontends, APIs, wallets, indexadores, bases de datos y controles operativos necesitan alcance propio. Una auditoría aporta evidencia adicional, no garantiza que no exista un exploit.

El esfuerzo y coste de los defectos varían según el sistema; la ilustración representa un concepto, no una curva medida.

Una lista práctica de revisión

• Comportamiento: ¿Puede el equipo definir criterios de aceptación e invariantes importantes antes de implementar?
• Modos de fallo: ¿Qué entradas malformadas, dependencias no disponibles, errores de permisos, reintentos y fallos parciales importan?
• Límites: ¿Qué es real, simulado o está expresamente fuera de la suite?
• Feedback: ¿La suite corre con rapidez y fiabilidad suficientes para influir en decisiones diarias?
• Seguridad: ¿Qué riesgos exigen análisis estático, fuzzing, revisión, auditoría, monitorización o controles operativos adicionales?
• Evidencia: ¿Qué gates de lanzamiento y señales de producción muestran comportamiento aceptable?

Cómo evaluar a un socio de ingeniería

No filtres un equipo con una pregunta ideológica como si siempre usa TDD. Pídele la estrategia para tus riesgos concretos. Una respuesta creíble identifica qué tendrá pruebas unitarias, qué necesita evidencia de integración o end-to-end, cómo se representarán sistemas externos, cómo se gestionan pruebas inestables, qué técnicas de seguridad complementan la suite y qué evidencia bloquea un lanzamiento.

Un proyecto sin pruebas automatizadas no muere inevitablemente, igual que una suite grande no garantiza el éxito. La decisión trata de riesgo y feedback. Prueba el comportamiento cuyo fallo importa, conserva la confianza en la suite y usa controles complementarios para lo que una prueba no puede demostrar.

Fuentes

• Martin Fowler: Test-Driven Development
• Smithsonian National Museum of American History: Log Book With Computer Bug
• OWASP Smart Contract Security Testing Guide