Verificar un plan con /test

Para qué sirve

Un plan se acuerda en una conversación y se construye en otra. /test es lo que corre la conversación de planeación cuando la de construcción reporta de vuelta: abre tu aplicación en tu navegador real, recorre punto por punto lo que el plan prometió y te entrega una tabla y un veredicto. Cuando algo falló, escribe la corrección: dentro del plan mismo cuando el plan está guardado en los documentos de tu proyecto, y como un prompt para que lo lleves de regreso cuando no lo está.

Verifica y nada más. No construye, no arregla lo que encuentra y no commitea. No corre ninguna prueba automatizada — ni la suite ni un solo caso — porque una suite en verde no dice nada sobre si el plan se cumplió en la pantalla. Y no revisa el código contra los estándares: el paso de construcción ya lo hizo, y /review es el comando para eso.

Rara vez tienes que escribirlo. Decir «revisa que funcione lo que planeamos» en la conversación de planeación basta, y dentro de la cola /next lo corre por ti.

Lo que necesita antes de empezar

• El plan. Lo toma de la conversación. Un plan guardado se revisa entero, con cada corrección que ya se escribió dentro de él. Un plan pegado en tu mensaje también sirve, con los prompts de corrección que se hayan escrito encima.
• La rama correcta. Nombra el repositorio y la rama, y te pregunta antes de seguir cuando no corresponden al trabajo que describe el plan.
• Un entorno local, un navegador y la aplicación corriendo. Confirma que el entorno es local antes de escribir nada, llega a tu navegador y arranca el servidor de desarrollo, en un puerto libre cuando el de siempre está ocupado.

Se detiene sin probar nada en tres casos: no hay plan, el plan nunca dice qué mirar, o la rama no corresponde y no lo has resuelto. Dice cuál de los tres es y qué lo destrabaría.

Cómo recorre el plan

El plan se vuelve una lista numerada de lo que prometió, y esa lista es lo que la tabla reporta, fila por fila. La primera fila siempre es el problema original: reproducido y confirmado que ya no pasa. A la lista no se le agrega nada leyendo el código; las únicas filas que se agregan después son los defectos que se describen abajo.

Cada fila se revisa en cada estado en el que el plan dice que tiene que funcionar — una lista vacía y una llena, una cuenta con suscripción y una sin ella — y el agente ux-designer revisa la experiencia de las pantallas que probó.

Cada pantalla en la que se prueba una fila pasa por las mismas revisiones, además de los estados que nombra el plan:

• cada idioma que sirve tu producto, sin claves de traducción en crudo y sin texto que se quedó en otro idioma;
• un ancho de teléfono, de tableta y de laptop — 375, 768 y 1280 píxeles;
• sin registros y con algunos, cuando la pantalla los lista;
• un indicador de carga mientras corre una acción que esperas;
• después de cada guardado, la página recargada para confirmar que el valor se quedó y que el mensaje de éxito dijo la verdad;
• un formulario de alta enviado vacío, que responde con su validación y nunca con una página de error;
• un nombre que un lector de pantalla pueda leer en cada botón que solo muestra un ícono.

Un defecto en una pantalla probada hace fallar una fila. Lo que salga mal ahí — encontrado por estas revisiones, por la revisión de ux-designer o sin buscarlo — hace fallar la fila que lo cubre, o una fila agregada para él que nombra el defecto, la pantalla y el estado. Esas son las únicas filas que se agregan después de armar la lista, y salen de lo que se vio, nunca del código. Un defecto ahí que necesita una decisión que solo tú puedes tomar no hace fallar ninguna fila: se nombra debajo del veredicto como una pregunta que el plan no ha respondido.

Los riesgos técnicos del plan se prueban desde la primera revisión. Un riesgo que el plan técnico nombra y que se ve en una pantalla — un ancho en el que tiene que caber una línea, datos que ya existen — se revisa como un estado más del punto al que toca, no como una fila nueva. Un riesgo que ninguna pantalla muestra, como el orden en que llegan los avisos de un proveedor, se nombra debajo del veredicto, y también un estado de riesgo que la revisión no alcanza — como no cubierto, sin pausar la corrida.

Un plan con un dibujo aprobado se compara contra él. Cuando aprobaste un dibujo al planear, cada pantalla que dibuja se pone junto a él: una diferencia en el acomodo, los componentes o los estados hace fallar el punto que la muestra. Sus datos de ejemplo no se comparan.

Cuando algo estorba, primero trabaja en ello. En un entorno local confirmado crea los registros que necesita un estado, entra con una cuenta sembrada, corre las migraciones que faltan, instala una dependencia de validación que falta y arranca lo que el flujo necesita, como un worker de colas. Un registro que ya existía nunca se borra, y uno que cambió se deja como estaba antes de terminar. Lo que escribió una instalación, como un lockfile, se nombra en el reporte y se deja como está, sin commitearlo.

Cuando eso falla, se pausa. Te dice qué está atorado y qué lo destrabaría, no entrega tabla ni veredicto, y nombra cualquier registro que cambió y que sigue esperando volver a como estaba. Cuando respondes, sigue desde donde se quedó, y el reporte cubre igual el plan entero.

Leer la tabla y el veredicto

El reporte es una tabla y un veredicto, sin nada encima.

Una fila probada en varios estados sigue teniendo un solo resultado: falla si falló en cualquiera de ellos, y la columna de estados dice en cuál. No existe «sin probar»: cada punto o se probó, o la corrida se pausó antes de escribir el reporte.

Debajo de la tabla, una línea: Pasa o No pasa. Dice No pasa cuando cualquier fila falló. No hay aprobación parcial.

Debajo del veredicto van líneas cortas que no lo cambian:

• Defectos notados cerca de lo que se probó, pero fuera de las pantallas y los flujos en los que se probaron las filas.
• Lo que propuso ux-designer, separado en lo que se puede escribir ya y lo que necesita su propia planeación.
• Lo que el plan mismo dejó contradictorio o sin definir, incluido un defecto en una pantalla probada que necesita tu decisión.
• El comportamiento que nadie ve en una pantalla, como un job o un comando, y los riesgos técnicos del plan que ninguna pantalla muestra. Un navegador no puede probarlos, así que se nombran aquí y nunca como fila.
• Las revisiones que no pudo hacer, como no cubiertas: un ancho al que no se pudo poner el navegador, un idioma al que no se pudo cambiar la pantalla, un indicador de carga que no pudo ver porque no logró hacer más lenta la petición, o un estado vacío al que solo llegaría una base de datos de prueba aparte.
• Lo que una instalación dejó en tu árbol de trabajo.

/test no crea ningún documento propio. Cuando lo llamó otro comando, un defecto notado fuera de las pantallas probadas se le entrega a ese comando para los Hallazgos pendientes de tu proyecto; corrido por sí solo, solo se nombra aquí.

La corrección

Cuando el veredicto es No pasa, /test escribe la corrección él mismo, sin preguntarte nada nuevo: lo que falló ya estaba planeado, y acaba de ver la falla.

Cuando el plan está guardado en los documentos de tu proyecto, la corrección va en ese mismo plan, en una sección llamada Validaciones al final, y no se crea ningún documento nuevo. Cada intento fallido agrega una entrada numerada:

• Qué se construyó o cambió en ese intento.
• Qué puntos se probaron, en qué pantalla y en qué estado, y cuáles pasaron.
• Por qué falló, dicho como comportamiento, con cómo se reprodujo.
• Lo que debe, tal como ya lo dice el plan.
• Las soluciones que se consideraron, la elegida y por qué.
• Lo que corrigió en el plan, como antes y ahora.
• Si la falla repite un intento anterior.

Cuando varias fallas comparten una causa, o un punto vuelve a fallar, la entrada agrega un replanteamiento: el patrón entre intentos, las preguntas sobre el plan que nadie ha respondido todavía y un enfoque distinto. En la tercera falla el replanteamiento siempre está, primero, porque es lo que lee /plan-prompt cuando el plan regresa ahí.

/test puede corregir un dato que el plan tenía mal — el nombre de una pantalla, cómo se comporta hoy un flujo — y la entrada anota qué decía antes y qué dice ahora. Nunca cambia lo que el plan pide: cuando la contradicción llega ahí, la entrada la nombra, no elige ninguna solución, y el plan regresa a /plan-prompt.

Cuando el plan nunca se guardó — pegado en la conversación — la corrección llega como un prompt con la misma forma que uno de /plan-prompt, que abre con la línea Origen: escrito por /test.. Llévalo a la conversación de construcción. Cuando algo de lo que partía ese plan resulta no ser cierto, no hay prompt: la afirmación y la evidencia regresan a /plan-prompt, y la tabla y el veredicto te llegan igual.

Antes de que la corrección salga, el agente analyst la revisa contra el código. Una duda que solo tú puedes resolver te llega como el hallazgo primero y la pregunta después, y la elección de la corrección espera tu respuesta.

Vuelve a correr /test cuando la corrección esté construida. Una segunda corrida prueba otra vez el plan entero, no solo lo que falló, porque una corrección puede romper algo que pasaba.

Cuando el veredicto es Pasa y ux-designer propuso algo que toca solo una pantalla que se probó y no necesita ninguna decisión que no hayas tomado, se te pregunta una vez si quieres un prompt para eso, o para parte de eso. Las otras propuestas se nombran, cada una con por qué necesita su propia planeación. Cuando el veredicto es No pasa, las propuestas solo se nombran: la pregunta llega en la corrida que pasa. Una corrida nunca escribe dos correcciones.

Después de que pasa, el siguiente paso es /finish.

Dentro de la cola

Cuando /next corre /test sobre los planes que construyó, no se pregunta nada: una pregunta se le devuelve a /next, que la escribe en el plan. Un plan construido en la cola se revisa sin la revisión de ux-designer y sin la revisión de analyst sobre la corrección. La corrección va en la sección Validaciones del plan, y la cola construye el mismo plan a partir de ella y lo vuelve a revisar, con tres intentos como máximo. Ese ciclo está en Correr la cola con /next.

Sigue por aquí

• Planear antes de construir — de dónde sale el plan contra el que revisa /test.
• Cómo viaja una tarea — la revisión en el navegador que el paso de construcción ya corre antes de que /test vea el trabajo.
• Qué hace cada comando — /test junto a /review y los demás.