


Corrige pruebas E2E fallidas observando el navegador real
Úsalo cuando falla una prueba E2E. Define el estado de éxito visible, ejecuta la prueba en un navegador real, reúne capturas y errores de consola, clasifica la causa en prueba, código o entorno, aplica el arreglo mínimo y repite hasta que pase o deba parar.
Para usar estas reglas de IA
## Define antes de probar cómo se ve el éxito en el navegador
Antes de ejecutar una prueba de extremo a extremo, convierte el comportamiento solicitado en condiciones que puedan observarse en el navegador real. Registra la URL o ruta inicial, el estado necesario de la cuenta o los datos de prueba, el área visible cuando sea relevante, las acciones del usuario y el resultado visible exacto que constituye el éxito. Incluye el estado de accesibilidad, la navegación, el estado persistente y el contenido obtenido mediante la red cuando formen parte del comportamiento.
- Prefiere roles orientados al usuario, etiquetas e identificadores de prueba específicos y estables antes que clases de estilo o posiciones en el DOM.
- Distingue la interfaz del ejecutor de pruebas de la aplicación sometida a prueba; las pruebas de una no describen automáticamente a la otra.
- Define tanto pruebas positivas, como una confirmación visible o un valor modificado, como pruebas negativas, como la ausencia de un aviso de error.
- Expresa las expectativas de tiempo mediante una condición de preparación observable, no mediante una demora arbitraria.
No debilites una aserción únicamente para que la prueba pase. Si el comportamiento esperado es ambiguo, detente y aclara el contrato de aceptación antes de modificar el código de prueba o del producto.
## Ejecuta la prueba en un navegador real y guarda capturas y registros
Inicia el escenario E2E pertinente de menor alcance en un navegador real compatible, siguiendo la ruta normal de la aplicación. Mantén explícitos la configuración, los datos de prueba, el estado de autenticación, el área visible y las funciones activadas, con suficiente detalle para repetir la ejecución. Si existe un modo con interfaz visible o un modo de depuración, úsalo cuando importen el estado visual o la interacción con el navegador.
Cuando ocurra un fallo, reúne pruebas antes de editar nada:
- el escenario que falló y la aserción o el comando exactos;
- una captura de pantalla o instantánea del navegador en el momento del fallo;
- el DOM de la aplicación alrededor del elemento objetivo, incluidos su nombre accesible y su estado;
- los errores pertinentes de la consola del navegador y las solicitudes de red fallidas o inesperadas;
- la URL actual, las redirecciones, los indicadores de carga y los mensajes de error visibles en la aplicación;
- las marcas de tiempo o los identificadores de ejecución necesarios para correlacionar los registros del servidor, cuando estén disponibles.
Realiza una inspección específica en lugar de volcar estados no relacionados. Reproduce el fallo una vez en las mismas condiciones cuando sea necesario distinguir un fallo estable de uno transitorio, pero no inicies un bucle de reintentos sin límite.
## Clasifica la causa del fallo: prueba, código o entorno
Clasifica el fallo observado como causado por la prueba, la implementación o el entorno. La clasificación debe estar respaldada por pruebas del navegador y, cuando sea necesario, por la inspección mínima pertinente del código fuente o los registros.
- Causa de prueba: el producto se comporta según el contrato de aceptación, pero la prueba usa un selector obsoleto, una aserción incorrecta, datos de prueba no válidos, una secuencia equivocada o una condición de preparación inadecuada.
- Causa de implementación: el comportamiento visible para el usuario infringe el contrato de aceptación, por ejemplo, un control no responde, el estado o la navegación son incorrectos, existe una regresión de accesibilidad o una solicitud de la aplicación falla debido al código del producto.
- Causa de entorno: la prueba y la implementación pueden ser correctas, pero falta un requisito previo o este no funciona correctamente, como un servicio no disponible, credenciales no válidas, un navegador incompatible, datos iniciales ausentes, una configuración errónea o recursos agotados.
Cuando las pruebas sean contradictorias, escribe hipótesis alternativas y ejecuta una sola comprobación discriminante cada vez. No clasifiques todos los tiempos de espera como problemas de prueba ni modifiques el código del producto únicamente porque una prueba haya fallado. Mantén la clasificación como provisional hasta que las pruebas descarten las alternativas más próximas.
## Aplica el arreglo mínimo sin debilitar las aserciones
Elige la corrección que resuelva la causa clasificada sin realizar una refactorización amplia. Conserva el contrato de aceptación y el comportamiento existente para el usuario fuera de la ruta que falla.
- Si la causa está en la prueba, actualiza únicamente el selector, la aserción, los datos de prueba, la secuencia de acciones o la condición de preparación que contradigan el estado observado del navegador.
- Si la causa está en la implementación, añade o conserva una prueba de regresión que falle cuando sea práctico y después modifica solo la porción mínima de la lógica del producto necesaria para restaurar el comportamiento especificado.
- Si la causa está en el entorno, repara o documenta el requisito previo ausente; no lo ocultes con esperas más largas, aserciones desactivadas o reintentos incondicionales.
- Prefiere señales deterministas, como una preparación visible, solicitudes completadas o un estado estable, antes que esperas de duración fija.
- Mantén neutrales para el usuario los cambios que faciliten las pruebas: añade identificadores estables o etiquetas accesibles sin vincular las pruebas a una disposición circunstancial.
Antes de editar recursos protegidos, generados, de producción, destructivos o que contengan credenciales, detente y obtén la autorización necesaria. Nunca expongas secretos en pruebas, registros, capturas de pantalla, datos de prueba ni informes.
## Repite el mismo escenario y para si los fallos se repiten
Después de la corrección, vuelve a ejecutar el escenario exacto que falló con las mismas condiciones del navegador y el mismo contrato de aceptación. Solo se considera aprobado cuando el navegador alcanza visiblemente el estado de éxito definido y el ejecutor no informa de ningún fallo oculto. Confirma que las pruebas de consola y red ya no muestran el error causal cuando esas señales hayan formado parte del diagnóstico.
Ejecuta después el menor ámbito de regresión afectado directamente: el escenario circundante, el archivo de funcionalidad o el grupo de pruebas estrechamente relacionado. No amplíes la ejecución a un conjunto completo no relacionado, salvo que el cambio tenga un impacto amplio o el usuario lo solicite expresamente. Si la nueva ejecución falla de otra forma, regresa a la recopilación y clasificación de pruebas en vez de acumular modificaciones especulativas.
Limita los intentos repetidos. Después de dos correcciones ineficaces con el mismo enfoque, reevalúa el diagnóstico y elige otra comprobación discriminante. Después de tres fallos consecutivos sin pruebas nuevas, detente e informa del bloqueo en lugar de seguir modificando el código base.
## Informa primero si pasó, falló o quedó bloqueado, con evidencias
Detente con éxito únicamente cuando se cumpla el contrato de aceptación original observable en el navegador, se apruebe el ámbito de regresión afectado directamente y no quede ningún error causal pertinente. Detente también cuando avanzar requiera una autorización que falta, credenciales, infraestructura no disponible, una acción destructiva o una decisión de producto que no pueda inferirse con seguridad.
Informa del resultado con pruebas suficientes para que otra persona pueda verificarlo:
- el escenario y las condiciones del navegador utilizados;
- el fallo observado y su clasificación;
- las pruebas que respaldaron la clasificación;
- el cambio mínimo realizado o el requisito previo sin resolver;
- las repeticiones exactas ejecutadas y sus resultados;
- el riesgo restante, las comprobaciones más amplias omitidas y la siguiente acción necesaria.
Comienza indicando aprobado, fallido o bloqueado. No declares que el trabajo está completo basándote únicamente en una inspección del código, una prueba unitaria aprobada o un DOM simulado cuando la condición de éxito dependa de un navegador real.
