Reintentar no es reparar
Pasar en el segundo intento no borra el primer fallo. Conserva ese dato, calcula el trabajo repetido y asigna un responsable al test inestable.
Edición traducida. Los identificadores técnicos permanecen en su forma original.
Considere una ejecución de lanzamiento ilustrativa: una prueba de pago falla, se ejecuta nuevamente y pasa. El tablero es verde. Nadie investiga. La próxima versión repite el patrón. Ha reducido la cantidad de paneles rojos sin saber si el pago es confiable.
Playwright distingue tres resultados en su guía de reintentos: aprobado en el primer intento, inestable después de un intento fallido seguido de éxito y fallido después de los intentos disponibles. Esas son pruebas diferentes. Una suite generada debería preservar la distinción en lugar de aplanar cada eventual paso hacia el éxito. El artefacto práctico de este artículo es un libro de reintentos que sobrevive al color final del tablero.
Lo que realmente cambia un reintento
Un reintento le da a la misma prueba otra oportunidad de ejecutarse. No corrige una comprobación débil, no repara un selector ni separa dos cuentas que sobrescriben la configuración de la otra. Playwright descarta un proceso de trabajo fallido e inicia otro. Sus ejemplos documentados muestran el gancho beforeAll ejecutándose nuevamente en el nuevo trabajador. Por lo tanto, la configuración y la limpieza pertenecen al cálculo de costes, no sólo los segundos pasados dentro del cuerpo de prueba.
Un nuevo navegador no es necesariamente una nueva base de datos. Si el primer intento creó una orden antes de fallar, el siguiente intento puede encontrar esa orden. Revise las pruebas generadas para detectar efectos secundarios externos e identifique si es seguro repetir la limpieza. Reintentar una compra contra producción no es un experimento aceptable; Utilice datos provisionales y una cuenta de prueba limitada.
El libro mayor que se debe mantener junto a CI
Para cada prueba, registre su identificador estable, resultado del primer intento, resultado final, recuento de intentos, vínculo de evidencia, causa sospechada, propietario y fecha de próxima revisión. Mantenga el fracaso del primer intento incluso si se aprueba el último intento. Un equipo sin un ingeniero de control de calidad dedicado puede asignar la propiedad al desarrollador propietario del flujo, en lugar de permitir que la automatización cree una cola sin propietario.
El libro mayor también es una superficie de revisión útil para las pruebas escritas por los agentes. Pídale al agente que redacte un escenario y luego haga que un humano verifique su configuración, comprobación y limpieza. Una política de reintento es una configuración de ejecución, no un sustituto de esa revisión. La página pública de AnyTest describe la exploración dirigida por URL y una revisión humana del conjunto; no establece cómo se debe elegir su presupuesto de reintento de CI particular.
Poner números al trabajo repetido.
Utilice un cálculo ilustrativo con supuestos explícitos. Supongamos que diez pruebas necesitan cada una un intento adicional que demora veinte segundos y reiniciar la configuración agrega cinco segundos por intento. Eso es diez veces veinticinco segundos, o 250 segundos de trabajo de ejecución adicional. No son necesariamente 250 segundos de retraso en el reloj de pared porque los trabajadores paralelos pueden superponerse. Registre tanto el trabajo del corredor como el tiempo transcurrido del proceso si la distinción es importante para su factura o ventana de lanzamiento.
Luego agregue el tiempo que alguien dedica a leer informes poco fiables. Si un agente ahorra una hora de creación pero deja una hora de investigación recurrente, el número de creación por sí solo no describe un ahorro. Para un equipo de control de calidad existente, el objetivo es menos repetición de trabajo y más tiempo para el análisis de riesgos. Para un equipo pequeño sin control de calidad, el objetivo es una cobertura útil que un desarrollador realmente pueda mantener.
Una regla de liberación que puedes explicar
Comience con una pequeña configuración de reintento limitada y una categoría inestable visible. Intensifique los repetidos fallos del primer intento en lugar de aumentar silenciosamente el límite. El umbral correcto depende del producto y del riesgo de liberación; No existe un recuento universal que haga aceptable un pago irregular. Adjunte un propietario de reparación y evidencia antes de aceptar una excepción.
La pregunta que se analiza es simple: ¿el segundo intento produjo nueva evidencia o simplemente un color que preferimos? Mantenga el intento fallido hasta que alguien pueda responder.
Preguntas comunes
¿Una prueba que se aprueba al reintentar es una prueba aprobada?
Dramaturgo clasifica un fracaso en el primer intento seguido de un reintento exitoso como poco fiable, no como un pase en el primer intento. Preserva esa distinción en los informes de lanzamiento.
¿Cómo debería un equipo medir el costo de reintento?
Cuente los intentos adicionales, la ejecución de pruebas, la configuración repetida y el tiempo de revisión. El trabajo del corredor y el retraso en la tubería del reloj de pared difieren cuando los intentos se superponen.
¿Los nuevos trabajadores de Playwright restablecen los datos del servidor?
Un trabajador y un navegador de reemplazo no borran automáticamente el estado de la aplicación externa. Diseñe una configuración y limpieza repetibles para los datos de preparación.