Pruebas y revisión de un guion por pares

Las pruebas de un guion que habla con una API no deben depender de la API real. Se graban respuestas de ejemplo (eventos y atributos ficticios con la forma que devuelve la instancia) y el guion se prueba contra ellas: cómo trata una página vacía, si registra los totales, si espera entre páginas, si nunca escribe cuando solo debe leer. Así las pruebas corren en segundos, dan siempre el mismo resultado y no ensucian la plataforma ni consumen el límite de búsquedas.

Lee pruebas.txt con cat: la primera línea dice cómo se corrieron.

Revisar un cambio es leer la diferencia (las líneas que empiezan por - se quitan, las que empiezan por + se añaden) contra la lista de revisión, punto por punto, y citar el punto que se incumple. La descripción del autor explica el porqué; la diferencia dice el qué. Cuando no coinciden, manda la diferencia.

Lee descripcion.txt, cambio.diff y lista-de-revision.txt. La primera modificación del cambio está en la línea que crea la conexión con la instancia.

La segunda modificación quita una línea dentro del bucle que pide páginas. El autor dice que ahora el guion termina en un minuto, y es verdad: lo que no dice es que esas peticiones seguidas cuentan contra el límite de búsquedas del rol y cargan una instancia que usan otros. Un guion más rápido no es mejor si llega antes a costa de los demás.

Una buena batería de pruebas atrapa la regresión aunque el revisor no la vea: alguien escribió en su día una prueba para la pausa entre páginas, y el cambio la rompe. El resultado de las pruebas es parte de la revisión; un cambio con una prueba en rojo no se aprueba, se devuelve con la prueba citada.

El equipo escribe los comentarios de revisión en inglés, porque el contratista trabaja con varios clientes y el repositorio es compartido. Un buen comentario de revisión dice la decisión, cita qué hay que cambiar y propone la salida correcta, sin juzgar a la persona. En comentarios-propuestos.txt hay tres borradores y solo uno se envía.