Esta es la rúbrica con la que juzgo si una suite de tests sirve. Está pensada para usarse, no para leerse una vez: guárdala y vuelve a ella.
Define “servir” como una sola cosa: que la suite se ponga roja cuando el producto se rompe, y solo entonces.
La escribí para auditar suites ajenas y la estrené con la mía, que sacó 15 sobre 21. Esa auditoría —con los dos hallazgos que me dejaron peor parada— está contada en Audité mi propia suite de tests. Acá está el instrumento; allá está lo que encontró.
Por qué una rúbrica y no otro checklist
Yo ya tenía tres checklists publicados: diez preguntas sobre confiabilidad, seis sobre las piezas de un framework, cuatro sobre el oráculo. Todos útiles, y ninguno alcanzaba.
Un checklist responde sí o no. Te orienta, no dictamina. Si tu suite tiene siete de diez, ¿aprueba? ¿Y si le faltan justo las tres que importan?
Una rúbrica agrega niveles: dice qué es un 0, un 1, un 2 y un 3 en cada dimensión. Con eso puedes poner un número, defenderlo con evidencia concreta y compararlo dentro de seis meses para saber si mejoraste o solo escribiste más tests.
Paso 0: para qué existe esta suite
Saltarte este paso hace que la rúbrica repruebe suites que están haciendo bien su trabajo. Me pasó con la mía la primera vez.
No todas las suites persiguen el mismo objetivo, y la primera dimensión asume uno solo. Antes de puntuar nada, escribe en una línea qué protege esto:
Red de regresión. El caso normal: protege el comportamiento correcto y los valores esperados salen de la especificación. Se puntúa tal cual.
Arnés de bugs fijados. Afirma a propósito un comportamiento incorrecto conocido, para enterarse si cambia. Verde significa “el bug sigue ahí”. Acá la primera dimensión no pregunta de dónde sale “correcto” sino si cada valor fijado es trazable a la decisión de fijarlo: el bug documentado y la regla que viola.
Caracterización de legado. Congela el comportamiento actual sin juzgarlo, como paso previo a refactorizar. Se puntúa como el anterior y se le anota fecha de caducidad.
Una suite mixta se puntúa por partes, nunca en promedio. Mezclar un arnés de bugs con una red de regresión en un solo número da un veredicto sin significado.
Las siete dimensiones
Cada una puntúa de 0 a 3. Máximo 21.
1 · Oráculo — de dónde sale “correcto”
Eliminatoria.
| Nivel | Cómo se ve |
|---|---|
| 0 | Los valores esperados salieron de correr el sistema. La suite congeló el comportamiento actual, bugs incluidos. |
| 1 | Mezcla: algunos asserts vienen del criterio de aceptación, otros de la salida observada. Nadie sabe distinguirlos. |
| 2 | Los valores salen de la especificación, pero no queda rastro de cuál regla los sostiene. |
| 3 | Cada valor esperado es trazable a una regla de negocio, y se podía escribir antes de ejecutar nada. |
Para responderla, las cuatro preguntas del goal verificable.
2 · Sensibilidad — si se pone roja por el motivo correcto
Eliminatoria.
| Nivel | Cómo se ve |
|---|---|
| 0 | Hay tests que no pueden fallar: sin assert, o asertan que la página cargó. Verde permanente. |
| 1 | Fallan, pero también fallan por cosas ajenas a lo que dicen proteger. |
| 2 | Fallan por lo suyo. Nadie lo verificó nunca de forma deliberada. |
| 3 | Se probó rompiendo la regla a propósito, o hay mutation testing corriendo. La sensibilidad está medida. |
3 · Determinismo
| Nivel | Cómo se ve |
|---|---|
| 0 | Se le da re-run hasta que pasa. El re-run es parte del proceso. |
| 1 | Hay flaky conocidos y tolerados; nadie tiene el número. |
| 2 | La flakiness está medida y bajo control. |
| 3 | Falla significa que hay un bug. Sin esperas fijas, sin dependencia de orden ni de estado compartido. |
4 · Diagnóstico — qué te dice cuando falla a las 3 a.m.
| Nivel | Cómo se ve |
|---|---|
| 0 | Un stack trace. Para saber qué pasó hay que reproducir a mano. |
| 1 | Log y poco más. Diagnosticar lleva más de media hora. |
| 2 | Hay trace, screenshot o payload, y el nombre del test dice qué comportamiento se rompió. |
| 3 | El reporte te dice qué regla de negocio dejó de cumplirse, sin abrir el código. |
5 · Cobertura de reglas de negocio
| Nivel | Cómo se ve |
|---|---|
| 0 | La cobertura se reporta en porcentaje de líneas. Nadie sabe qué reglas están sin cubrir. |
| 1 | Solo happy paths. |
| 2 | Hay negativos y límites, sin criterio explícito de qué se automatiza y qué no. |
| 3 | Puedes listar qué reglas cubre la suite y cuáles quedan fuera a propósito. |
6 · Vida en CI
| Nivel | Cómo se ve |
|---|---|
| 0 | Corre en la máquina de alguien, cuando se acuerda. |
| 1 | Corre en CI, pero no bloquea nada y el reporte no lo mira nadie. |
| 2 | Corre en cada push y bloquea el merge. |
| 3 | Además el verde es condición para desplegar, y los fallos tienen dueño. |
7 · Mantenibilidad
| Nivel | Cómo se ve |
|---|---|
| 0 | Copy-paste, nombres genéricos, selectores frágiles. |
| 1 | Hay estructura, pero los nombres describen implementación en vez de comportamiento. |
| 2 | Nombres de negocio y capas separadas; queda duplicación. |
| 3 | Los tests pasan por review como el código de producción, y hay proceso para retirar los que ya no aportan. |
El veredicto
Las dos eliminatorias mandan sobre el total.
Si la 1 o la 2 puntúan 0, no aprueba, sin importar la suma. Una suite que congeló los bugs de hoy, o que no puede ponerse roja, no es una red de seguridad: es un decorado caro que además da confianza.
Con las eliminatorias en 1 o más:
| Puntos | Veredicto |
|---|---|
| 0-9 | No aprueba. La suite da falsa seguridad; hoy es un pasivo. |
| 10-14 | No aprueba todavía. Base real, huecos que se arreglan. |
| 15-18 | Aprueba. Suite confiable con deuda identificada. |
| 19-21 | Aprueba con distinción. |
El número importa menos que la evidencia que lo sostiene. Un puntaje sin archivo y línea es una opinión con decoración.
Cómo aplicarla sin que te lleve un día
No empieces por la dimensión 1. Empieza por la que da resultados en quince minutos.
El recorrido corto: tres cortes antes de puntuar nada
Corte 1 — El conteo de skipped. Abre la última corrida verde de tu CI y busca el número de tests salteados, no el de pasados. Si no es cero, esos tests figuran en tu total y nadie sabe cuál sería su resultado. Eso es la dimensión 6.
Corte 2 — Cinco asserts al azar. Pregunta de dónde salió cada valor esperado. Si la respuesta honesta es “de correr el sistema y ver qué daba”, tienes una foto del comportamiento actual con los bugs de hoy adentro. Eso es la dimensión 1.
Corte 3 — Un test roto a mano. Elige un test y rompe la regla que dice proteger. ¿Se pone rojo? ¿Y si rompes otra cosa, se queda quieto? Si no se pone rojo, ese test no cuida nada. Eso es la dimensión 2.
Con esos tres cortes ya sabes si la suite aprueba o no, porque dos de ellos son eliminatorios. Las otras cuatro dimensiones te dicen cuánto trabajo tienes por delante, no si estás aprobada.
Qué anotar mientras puntúas
Para cada dimensión, tres cosas y nada más:
- El nivel, de 0 a 3.
- La evidencia: archivo y línea. No adjetivos.
- Qué lo subiría un punto.
Al terminar, ordena esas siete respuestas por retorno y quédate con las tres primeras. El resto es ruido para los próximos dos meses.
Puntuar alto porque la suite está bien escrita. La calidad del código de tests y la calidad de la información que te dan son cosas distintas: se puede tener una suite impecable que en CI ejecuta la mitad. La primera se ve leyendo; la segunda solo se ve preguntándole al pipeline qué corrió de verdad.