Espera el resultado, no el reloj.

Un formulario de configuración se guarda lentamente. Alguien agrega una pausa de dos segundos antes de verificar el mensaje de éxito. Pasa en su computadora portátil. La siguiente ejecución de CI tarda un poco más y falla. Otro desarrollador cambia la pausa a cinco segundos. La prueba ahora es más lenta, pero aún falta la razón por la que debería continuar.

La pregunta útil no es cuántos segundos hay que dormir. Es lo que la evidencia dice que el siguiente paso está listo. Esta guía crea una pequeña verificación de la configuración guardada en torno a esa pregunta, utilizando la documentación de afirmación de Playwright y su guía de mejores prácticas. La captura de pantalla es una demostración local ilustrativa, no una aplicación de cliente ni una prueba comparativa de producto.

Una pausa adivina. Se comprueba una condición.

En la demostración, al hacer clic en Guardar se cambia un elemento de estado de Guardado a Guardado después de un retraso. Una consulta de visibilidad inmediata toma una instantánea del presente. No espera un estado futuro. Las primeras afirmaciones web de Playwright verifican repetidamente el localizador hasta que se cumple la condición esperada o expira el tiempo de espera.

Compare los dos enfoques en una prueba en la que una página ya ha navegado a su propio formulario de configuración de preparación:

// A fixed delay does not express the requirement.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await page.waitForTimeout(2000);
expect(await page.getByRole('status').innerText()).toBe('Saved');

// The expected state controls when the check finishes.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await expect(page.getByRole('status')).toHaveText('Saved');

Estos son fragmentos alternativos, no instrucciones para hacer clic dos veces en una prueba. La segunda afirmación puede finalizar tan pronto como aparezca Guardado. Si nunca aparece, la afirmación falla en lugar de esperar indefinidamente. El tiempo de espera de aserción predeterminado es de cinco segundos según la documentación de aserción actual; elija un tiempo de espera local sólo cuando el comportamiento esperado de su producto lo justifique.

La espera automática no es lo mismo que la espera de resultados

Playwright comprueba la capacidad de acción antes de acciones como un clic. Es posible que un botón deba ser visible, estable, habilitado y capaz de recibir eventos. Eso responde si el clic puede ocurrir. No prueba que la solicitud de guardado finalizó o que el servidor mantuvo la nueva configuración.

Un estado de éxito puede ser una condición de preparación razonable para el siguiente paso de la interfaz de usuario, pero no es una prueba independiente de persistencia. Mantenga esos trabajos separados: espere a que se guarden, vuelva a cargar la página de configuración y luego verifique el valor seleccionado. Nuestro artículo anterior sobre resultados independientes analiza ese límite de prueba; Esta guía se centra en el mecanismo de sincronización que le permite realizar el cheque de forma fiable.

await expect(page.getByRole('status')).toHaveText('Saved');
await page.reload();
await expect(page.getByLabel('Display name')).toHaveValue('Demo user');

El ejemplo supone un campo accesible llamado Nombre para mostrar y un registro provisional seguro para recarga. Defina esos contratos en la demostración o en su aplicación. No cambie el perfil de un usuario en vivo para que un experimento de sincronización sea conveniente.

Cuando la espera falle, no la infles primero.

Un tiempo de espera de aserción vencido es evidencia para inspeccionar. Es posible que el estado nunca se actualice. La prueba podría apuntar a un componente antiguo. La salvación podría fallar. O, legítimamente, el producto podría tardar más que la expectativa actual. Inspeccione la acción y la interfaz de usuario resultante antes de cambiar un tiempo de espera.

La guía de capacidad de acción de Playwright explica qué acciones esperan y qué afirmaciones se reintentan. Las comprobaciones de igualdad genéricas no adquieren ese comportamiento simplemente porque dentro de ellas hay un valor esperado. Prefiere una afirmación de localizador para una condición cambiante de la interfaz de usuario; utilice una afirmación de sondeo acotada cuando la condición esté fuera de esa forma.

Evite convertir cada error en un tiempo de espera compartido mayor. Un techo más largo oculta los síntomas y puede hacer que una carrera interrumpida tarde mucho más tiempo. Anote la señal de preparación prevista y a quién pertenece. Si no existe ninguna señal, un estado de carga más claro o un contrato de prueba pueden ser una mejor solución que otro modo de suspensión.

Una tarjeta de revisión para las pruebas generadas

Para cada paso sensible al tiempo, registre la acción, la condición de preparación, el motivo del tiempo de espera y la verificación del resultado final. En nuestra demostración: Guardar, el estado es igual a Guardado, la ventana de respuesta de guardado acordada, luego el campo persiste después de la recarga. Esta pequeña tarjeta es más fácil de revisar que un montón de pausas.

AnyTest describe a los agentes que exploran una aplicación web y crean pruebas de un extremo a otro para revisión humana. Si un flujo generado parece demasiado rápido o poco confiable, el revisor debe preguntar qué hace que cada transición esté lista. Este es un principio de revisión, no una afirmación de que AnyTest exponga la configuración de Playwright o el código generado en un formato particular.

Un único ingeniero de QA se beneficia cuando las reglas de sincronización son lo suficientemente explícitas para que las mantengan los desarrolladores. Un equipo sin QA dedicado puede usar la misma tarjeta durante la revisión del código. El objetivo es una prueba que espera la razón correcta, falla con un límite útil y nunca confunde una pausa con una prueba.