CP//DEV

1/3/2026 · 7 min de lectura

Epistemología para developers: quién comprueba los tests

Los escépticos antiguos preguntaron con qué criterio se valida el criterio. Una suite en verde tiene ese mismo problema, y casi nadie se lo plantea.

Mil cuatrocientos tests en verde, ochenta y siete por ciento de cobertura, y el despliegue del jueves dejó el checkout aceptando pedidos sin cobrarlos. En el postmortem apareció el test que cubría exactamente esa ruta. Pasaba. Llevaba once meses pasando.

Estaba escrito a partir del código, no del requisito. Afirmaba lo mismo que la función, con otras palabras, y por eso no podía contradecirla nunca. El verde no era una comprobación: era un eco.

Esa suite no medía el sistema. Se medía a sí misma.

La pregunta que nadie hace en la retro

Un test decide si el código está bien. La pregunta incómoda viene después: ¿quién decide si el test está bien?

La respuesta habitual del equipo, si se la sacas, es circular. El código está bien porque los tests pasan. Los tests están bien porque el código funciona en producción. Cada mitad se apoya en la otra y el conjunto no se apoya en nada.

La alternativa tampoco sale gratis. Se puede poner algo por encima que vigile los tests —revisión obligatoria, cobertura mínima, un linter de aserciones—, pero entonces hace falta algo que garantice que la revisión revisa, que la cobertura mide lo que dice medir, que la regla del linter era la correcta. Cada nivel de vigilancia necesita el suyo. No hay un último.

O el criterio se justifica a sí mismo, o se justifica con otro que a su vez necesita otro. Círculo o escalera infinita.

Un problema con dos mil años

No es un problema de nuestro oficio. Es el problema, y se formuló hace mucho.

Los escépticos griegos lo llamaron sin adornos el problema del criterio. Para zanjar una disputa hace falta una medida aceptada por las dos partes. Pero si la disputa es precisamente sobre cuál es la medida, no hay dónde apoyarse: justificarla con otra medida abre una serie sin final, y justificarla consigo misma es dar por bueno lo que se discutía. Sexto Empírico lo dejó escrito con esa frialdad de manual que todavía incomoda leer.

Contra ese argumento estaban los estoicos, que sostenían algo muy parecido a lo que sostiene un equipo con buena suite: que hay impresiones que traen su propia garantía, tan claras y tan bien impresas que no podrían venir de algo inexistente. Zenón lo enseñaba con la mano. Abierta, la impresión que llega. Los dedos plegados, el asentimiento. El puño cerrado, la comprensión. Y la otra mano apretando ese puño, la ciencia.

Toda la ofensiva escéptica consistió en mostrar que para cualquier impresión de esas se puede construir otra indistinguible y falsa. No que nos engañemos siempre. Que no hay marca en la impresión que garantice cuál es cuál.

Traducido: no existe el verde que traiga su propia garantía. Para cualquier suite que pasa hay otra suite indistinguible que también pasa y cubre un sistema roto. La que teníamos aquel jueves era esa.

Los escépticos no dejaron de vivir

Aquí está el giro que importa, porque el argumento anterior, tomado en crudo, lleva a un sitio inútil: si nada garantiza nada, no despliegues nunca. Nadie trabaja así, y los escépticos tampoco vivían así.

Distinguían dos cosas que en el oficio confundimos todo el rato. Una es el criterio de verdad, el que garantizaría que algo es así. Ese es el que demolían. Otra es el criterio práctico, la pauta con la que uno se conduce: lo que aparece, lo que el cuerpo pide, la costumbre del sitio y el adiestramiento de un oficio. Esa la aceptaban sin problema, con una condición: no tomarla por verdadera.

Una suite de tests es lo segundo. Es una guía de conducta muy buena, destilada del oficio, que te dice dónde mirar y en qué orden moverte. No es una prueba de que el sistema esté bien. Funciona bien mientras se use como lo que es, y falla el día que alguien la asciende a garantía y deja de mirar.

Casi todo el daño que he visto viene de ese ascenso, no de la falta de tests.

Los tres grados de Carnéades

Carnéades, que dirigió la Academia y no escribió una línea, dejó lo más aprovechable de todo esto: una escala. Frente a una impresión que no puedes garantizar, todavía puedes graduar cuánto te apoyas en ella. Distinguía tres niveles, y su ejemplo era examinar a los candidatos a un cargo público.

El primero: la impresión es convincente por sí sola. La miras y te persuade.

El segundo: además, nada de lo que la rodea la contradice. Has mirado alrededor y todo acompaña.

El tercero: además, la has examinado a conciencia, punto por punto, buscando por dónde podría fallar.

Conviene decir que su palabra no significaba «probable», aunque se tradujo así durante siglos y el error todavía circula. Significaba convincente. No es una medida de cuánto se acerca algo a la verdad; es una medida de cuánto te ha persuadido a ti. La diferencia no es menor: la primera pretende hablar del mundo, la segunda admite que habla del observador.

Sobre tests, la escala se lee sola.

Grado uno: el test pasa. Convence por sí solo. La mayoría de las suites del mundo viven aquí y aquí se quedan.

Grado dos: nada más lo contradice. Los tipos cuadran, el test de al lado sigue en verde, el consumidor de esa API no se ha quejado, staging lleva una semana comportándose. Ninguna de esas cosas prueba nada por separado. Juntas, y siendo independientes entre sí, valen bastante más que la primera.

Grado tres: alguien intentó tumbarlo a propósito. Mutar el código para comprobar que el test se pone rojo. Un caso de carga real. Una revisión hostil. Un test escrito por quien no escribió la función, desde el requisito y sin abrir la implementación.

El grado tres es caro. Por eso no va en todas partes: va donde el fallo se paga en dinero, en datos o en confianza. En el resto, el grado dos ya es un lujo razonable.

Lo que cambié después de aquel jueves

Cuatro cosas, y ninguna es comprar más cobertura.

  • Un test escrito a partir del código no es evidencia. Es una copia notarial de la implementación. Se escribe desde el requisito, antes o aparte, o lo escribe otra persona. Si sale del mismo sitio que el código, hereda sus errores enteros.
  • Verlo fallar antes de verlo pasar. Un test que nunca ha estado en rojo no ha demostrado ni siquiera que sea capaz de fallar. Es la comprobación más barata que existe y la que más se salta.
  • Buscar evidencia de otra clase. Ante algo importante, la pregunta no es «¿pasa el test?» sino «¿qué otra cosa, que no dependa de esta, apunta a lo mismo?». Dos pruebas que comparten el mismo supuesto son una sola prueba dicha dos veces.
  • Nombrar el grado. Al cerrar un PR sé si voy en grado uno o en grado dos, y lo digo. No para ser riguroso de cara a la galería, sino porque el que despliega merece saber sobre qué se apoya.

Dudar cuesta, y por eso se administra

La conclusión no es dudar más. Dudar tiene precio y el presupuesto es finito: cada hora gastada en asegurar el borde es una hora que no está puesta en el núcleo.

Lo que cambia es dónde se pone. Hay una parte del sistema donde un error se corrige el martes siguiente y no ha pasado nada, y ahí el grado uno sobra. Y hay otra donde un error se descubre seis meses después leyendo una reclamación, y ahí ni el grado tres es exagerado.

En el bug que no existe el asunto era el hueco entre lo que el sistema hace y lo que el sistema cuenta de sí mismo. Esto es el mismo hueco visto antes de que aparezca nadie a habitarlo.

Los escépticos no ganaron la discusión, entre otras cosas porque no pretendían ganarla. Lo que dejaron es más útil que una victoria: la costumbre de preguntar, delante de cualquier cosa que te dé confianza, de dónde le viene a ella la suya. Un verde no responde esa pregunta. Solo la aplaza hasta el jueves.

Sigue leyendo