Tests como contratos vivos

La mayoría trata los tests como una tarea pesada: prueba para el gate de CI, un impuesto sobre lanzar. He llegado a verlos como algo más útil — el contrato que tu código firma sobre cómo se supone que debe comportarse. A diferencia de un comentario o una página de wiki, este contrato no puede quedar desactualizado en silencio, porque en el momento en que deja de ser cierto, falla.

Documentación que no puede mentir

Un test dice "dada esta entrada, el sistema promete esta salida". Eso es documentación con dientes. Un README puede describir un comportamiento que cambió hace tres commits; un test describe un comportamiento que es cierto ahora mismo, o el build está en rojo. Cuando quiero entender qué garantiza de verdad un módulo, leo sus tests antes que su prosa.

De ejemplos a propiedades

Los tests de ejemplo verifican casos específicos. Los tests de propiedades verifican reglas que siempre deben cumplirse, a lo largo de cientos de entradas generadas. En un proyecto como BillParty, el contrato no es "repartir $30 entre tres da $10 a cada uno" — es "las partes siempre suman el total", para cualquier monto y cualquier reparto. Enuncia la propiedad, deja que la herramienta cace el contraejemplo. Cuando no encuentra ninguno, has verificado una ley de tu sistema, no una sola anécdota.

Prueba el dominio, no el framework

Los contratos que vale la pena escribir son sobre las reglas de tu dominio — la matemática, los invariantes, las cosas que nunca deben romperse. El framework ya tiene sus propios tests; no necesitas re-verificar que el router enruta. Apunta tu suite al núcleo, donde equivocarse es caro, y deja que monte guardia ahí.

Tratados así, los tests dejan de ser sobrecarga. Se vuelven la descripción viva y exigida de lo que tu software promete — y lo que te permite cambiar todo lo demás con confianza.