Lee las pruebas antes que el código
Revisa primero las pruebas. El código después. La mayoría de los revisores abren un pull request y bajan directo a la implementación: la función nueva, la rama modificada, el refactor ingenioso. Pero el diff ya contiene una especificación en lenguaje claro de lo que el cambio debe hacer: las pruebas. Léelas primero y revisarás con la intención en la mano, en lugar de deducirla del código.
Por qué las pruebas van primero
Una prueba es el autor diciéndote, en forma ejecutable, qué comportamiento garantiza este cambio. Nombra las entradas, las salidas esperadas y los casos límite que el autor consideró importantes. Ese es el contrato. La propia guía de revisión de código de Google pone a las pruebas en la lista corta de lo que un revisor debe evaluar activamente —no ojear— porque "las pruebas no se prueban solas, y rara vez escribimos pruebas para nuestras pruebas; un humano debe asegurarse de que las pruebas sean válidas."
Si lees primero el código, gastas tu atención descifrando cómo funciona. Si lees primero las pruebas, ya sabes qué debe hacer, así que cuando leas el código lo estás verificando contra una especificación en vez de adivinarla. Además, las pruebas envejecen mejor que los comentarios: son documentación viva que falla cuando el comportamiento se desvía, así que lo que lees en el diff está vigente, no obsoleto.
El mecanismo
- Lee primero las pruebas del diff. Anota los comportamientos que afirman y los casos límite que cubren. Esa es la intención declarada del autor.
- Lee el código contra ellas. Ahora cada línea responde una pregunta que ya planteaste: ¿esto cumple el contrato que describen las pruebas?
- Busca el hueco. El cambio toca una ruta riesgosa: una rama nueva, un caso de error, una ventana de concurrencia, un límite. ¿Hay una prueba para eso? Un cambio riesgoso sin prueba en su ruta riesgosa es en sí mismo un hallazgo. Escribe ese comentario.
| Lo que ves en el diff | Qué verificar | Señal de alerta |
|---|---|---|
| Una prueba nueva | ¿Fallará cuando el código se rompa? | No afirma nada que pueda salir mal |
| Una prueba modificada | ¿Por qué cambió la expectativa? | Se relajó para dejar pasar un bug |
| Una rama / ruta de error nueva | ¿Hay una prueba que la ejercite? | Ruta riesgosa sin prueba |
| Ningún cambio en las pruebas | ¿Debería haberlo? | "Refactor" que altera el comportamiento |
Verde no es revisado
Que las pruebas pasen significa que el código cumple las pruebas que existen. No dice nada de las pruebas que deberían existir. Un cambio puede estar completamente en verde y aun así entregar un modo de fallo sin prueba: el check verde de CI solo cubre las rutas que alguien se acordó de escribir. Leer primero las pruebas es como atrapas la ruta riesgosa que el cambio introdujo en silencio, porque comparas el conjunto de comportamientos probados con el conjunto de comportamientos modificados y buscas la diferencia.
Para el usuario avanzado
- Hazle a la prueba las preguntas del revisor. ¿Fallará de verdad cuando el código se rompa? ¿Empezará a dar falsos positivos la próxima vez que el código de abajo se mueva? ¿Cada afirmación dice algo simple y útil? Una prueba que no puede fallar es decoración.
- Vigila la afirmación relajada. El diff más peligroso es una prueba cuyo valor esperado cambió sin explicación. Eso suele ser un bug siendo ratificado. Haz que el autor justifique cada expectativa relajada.
- Úsalo para guiar a tu agente. Cuando un agente de IA abre un PR, apúntalo también primero a las pruebas: "revisa las pruebas de este diff, luego el código, y marca cualquier comportamiento modificado sin prueba." Las pruebas le dan al modelo el mismo anclaje que te dan a ti: intención contra la cual verificar el código, en lugar de narrarte la implementación de vuelta.
- Pruebas antes que código en TDD, pruebas antes que código en la revisión. La simetría no es casualidad: quien lee el contrato primero hace mejor trabajo.
Recursos
- What to look for in a code review — la sección Tests (Google eng-practices)
- The Standard of Code Review (Google eng-practices)
- Unit Tests as Documentation: por qué las pruebas son documentación viva (The Coder Cafe)
- Revealing Code Intent With Tests (Kostadin Golev)
<div class="cta"> <p><strong>¿Despliegas agentes de IA que revisan o escriben código?</strong> Yeda AI diseña, audita y entrega sistemas LLM en producción.</p> <p>Más tips en la serie · <a href="/contact">Habla con nosotros</a></p> </div>