Avance el reloj, no el tiempo de ejecución de la prueba.

Aparece un recordatorio después de un largo período de inactividad. La prueba espera durante todo el período. Eso hace que la ejecución de la suite sea costosa, por lo que alguien reduce el retraso en una compilación especial. Ahora la prueba ya no ejerce la misma regla de tiempo. El tiempo de navegación controlado ofrece otro camino, siempre que el resultado se nombre honestamente.

Esta guía utiliza la documentación del reloj de Playwright para comprobar un pequeño recordatorio local. Su imagen es una cuenta regresiva inventada, no una sesión de producción o un punto de referencia de desempeño. Controlamos el tiempo del navegador para ejercer el comportamiento seleccionado. No afirmamos que adelantar ese reloj cambie un servidor remoto, caduque un token real o recree cada condición de programación.

Separe el reloj de pared del cronómetro.

Una aplicación puede leer la fecha actual, programar un tiempo de espera o actualizarse en un intervalo. Esos mecanismos están relacionados, pero una prueba necesita saber cuál impulsa el comportamiento. Una etiqueta de fecha que dice mañana y una devolución de llamada que se activa en sesenta segundos son contratos diferentes.

La guía de reloj de Playwright describe el control de las API de tiempo, incluidas la fecha y los temporizadores. Su método de tiempo fijo cambia el tiempo informado sin hacer avanzar los temporizadores. La instalación del reloj proporciona una configuración controlada más amplia. Elija el método de la regla real de la aplicación, no del ejemplo que sea más fácil de pegar.

Para nuestra demostración, la página programa un recordatorio a través de setTimeout. Instale el reloj controlado antes de que comience el código de tiempo de la página. Luego, avance deliberadamente en el cronograma de devolución de llamadas:

await page.clock.install();
await page.setContent(`
  <p role="status">Waiting</p>
  <script>
    setTimeout(() => {
      document.querySelector('[role=status]').textContent = 'Reminder ready';
    }, 60000);
  </script>
`);
await page.clock.runFor(60000);
await expect(page.getByRole('status')).toHaveText('Reminder ready');

El fragmento utiliza un elemento HTML local y un expectativa Playwright importada. Es un ejemplo de mecanismo, no una función de recordatorio completa. La prueba también debe comprobar qué puede hacer una persona después de que aparece el recordatorio y qué sucede cuando lo descarta. El avance del tiempo no puede suplir esas decisiones de producto.

Elige cómo se comportan las devoluciones de llamadas perdidas

La guía del reloj distingue el avance de los cronómetros del salto de tiempo. Lea esa distinción antes de reemplazar una larga espera. Un sistema que se actualiza una vez por segundo puede comportarse de manera diferente si se ejecuta cada devolución de llamada programada versus un salto que simula un navegador que se activa después de una pausa.

Utilice runFor cuando el escenario seleccionado requiera avanzar con devoluciones de llamada programadas. Considere fastForward para un escenario diferente en el que el comportamiento de sincronización perdida es importante, siguiendo la semántica documentada. No trate las dos operaciones como intercambiables simplemente porque ambas llegan a un momento posterior. El nombre de una prueba debe decir qué situación representa.

Mantenga un estuche pequeño para el límite justo antes del recordatorio y otro para el punto en el que debería aparecer. Para un temporizador repetitivo, agregue la regla de repetición solo si la función lo promete. Una sola afirmación final puede pasar por alto un recordatorio temprano o varias notificaciones duplicadas.

La hora del navegador no es el reloj del servidor

Una sesión real puede caducar según la política del servidor. Mover el reloj del navegador no cambia esa política. Una cuenta regresiva de la UI puede indicar que ha caducado mientras el servidor aún acepta la solicitud, o el servidor puede rechazarla antes de que la UI se dé cuenta. Esas son diferentes piezas de evidencia para probar por separado.

Para una característica autenticada, establezca si la fuente de verdad es una respuesta del servidor, una marca de tiempo de vencimiento o un temporizador local. Utilice entradas de preparación aprobadas e identidades controladas. Nunca cambie la sesión de una cuenta real o el reloj del sistema de una máquina simplemente para que sea conveniente realizar una verificación de tiempo ilustrativa.

La zona horaria y la ubicación son otro límite. Una prueba de temporizador no valida automáticamente una fecha límite del calendario en torno a los cambios de horario de verano o la fecha mostrada en cada ubicación. Agregue esos casos del requisito real en lugar de ampliar el significado de un resultado verde.

Deje un contrato de tiempo útil para los revisores

Registre la fuente de tiempo, el mecanismo instalado, el estado inicial, la operación avanzada y el límite esperado. Esa breve nota le permite a un compañero de equipo comprender por qué la prueba no duerme por un minuto y qué comportamiento aún protege. Si la prueba falla posteriormente, inspeccione si la aplicación movió el tiempo a otra capa antes de aumentar las esperas arbitrarias.

AnyTest describe agentes que exploran una aplicación y crean pruebas de un extremo a otro para revisión humana. Utilice el contrato de temporización para revisar cualquier viaje de vencimiento propuesto. Esta guía no afirma ninguna función de control de reloj AnyTest ni integración de corredor. Las pruebas más rápidas son útiles cuando el atajo conserva la pregunta, no cuando la sustituye silenciosamente por un reloj diferente.