Epistemología para developers: cómo dudar bien del código

El problema de la inducción en tests

“Todos los cisnes son blancos — hasta que aparece uno negro.”

Karl Popper lo dejó claro: no podemos verificar teorías, solo falsarlas. Cada test que pasa no prueba que tu código funciona, solo que no has encontrado todavía el caso que lo rompe.

Falsacionismo y TDD

TDD formaliza el falsacionismo: primero escribes el contraejemplo (un test rojo), y solo después un código que sobrevive a ese ataque. No estás probando que funciona — estás probando que este caso específico no rompe.

Tu código como hipótesis

Cada función es una hipótesis sobre cómo debe comportarse el sistema. Los tests son intentos de refutarla. El código es provisional, como toda hipótesis científica: válido hasta que aparezca el cisne negro.

Cuándo parar de dudar

Quine nos recuerda que no todas las creencias se revisan a la vez. Hay un núcleo (invariantes del dominio) que protegemos y una periferia (detalles de implementación) que reescribimos cuando aparece evidencia nueva.

Escribe tests para el núcleo. En la periferia, duda menos y envía.