Simula la dependencia. Marca el límite.

Una cotización de entrega falla durante una verificación de liberación. ¿Está rota la interfaz de usuario de pago, el proveedor de cotizaciones no está disponible o el entorno de prueba ha perdido sus credenciales? Un resultado rojo ahora representa varios sistemas. Una respuesta controlada puede ayudarle a examinar la interfaz de usuario, pero cambia el significado del resultado.

Esta guía utiliza una pequeña pantalla de cotización de entrega para mostrar cómo simular una dependencia y etiquetar la evidencia de manera honesta. Se basa en la [guía burlona de Playwright] (dependencia de https://playwright.dev/docs/simulated) y la documentación de red. La pantalla que se muestra aquí es una demostración local ilustrativa con opciones de envío inventadas, no un flujo de trabajo del cliente ni un servicio en vivo.

Decide qué pregunta responde la prueba

La pregunta de la interfaz de usuario es si la página muestra un precio devuelto, maneja una lista vacía y explica una cotización no disponible. La cuestión de la integración es si el servicio real acepta la solicitud y devuelve la forma de respuesta acordada. Puede probarlos por separado y mantener una verificación de servicio real más pequeña junto a un conjunto de interfaz de usuario determinista.

No llame a la ruta simulada evidencia completa de extremo a extremo para el servicio. Su valor es más limitado: su interfaz recibe datos conocidos y se comporta correctamente. Esta es una evidencia útil cuando se nombra correctamente. Una dependencia simulada verde no puede indicarle si un proveedor cambió sus credenciales, rechazó su carga útil o dejó de prestar servicios en su región.

Instalar la ruta antes de que ocurra la solicitud.

En esta aplicación ilustrativa, al cargar la página de cotización se solicita /api/delivery-quote. El ejemplo intercepta esa ruta exacta y devuelve un objeto JSON controlado. Registre el controlador antes de navegar para que la primera solicitud no pueda escapar de la configuración prevista.

await page.route('**/api/delivery-quote', async route => {
  await route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify({ label: 'Standard', price: '4.00' })
  });
});
await page.goto('/delivery-quote');
await expect(page.getByRole('status')).toHaveText('Standard: 4.00');

Utilice una URL base provisional configurada para esta navegación relativa. La forma de respuesta es nuestro contrato de demostración, no una API de entrega universal. Una prueba real debería utilizar su esquema documentado y sus reglas monetarias. Haga coincidir solo el punto final que desea controlar; interceptar todo el tráfico puede ocultar fallas no relacionadas.

La API de ruta de Playwright distingue entre cumplir una solicitud y obtener una respuesta real y modificarla. El ejemplo anterior no llama al servicio de cotización ascendente. Un ejemplo de route.fetch() tendría un límite diferente porque aún depende de la respuesta ascendente.

Estados de falla de prueba sin esperar a que se produzca una interrupción del proveedor

Devuelva una respuesta 503 en una segunda prueba, luego verifique que la página explique que la cotización no está disponible y ofrezca la siguiente acción prevista. Una tercera prueba puede devolver un resultado vacío exitoso si ese es un estado significativo en su contrato. Mantenga cada configuración pequeña y explícita.

await page.route('**/api/delivery-quote', route =>
  route.fulfill({ status: 503, body: 'Unavailable' })
);
await page.goto('/delivery-quote');
await expect(page.getByRole('alert')).toHaveText('Quote unavailable');

Estos fragmentos pertenecen a casos de prueba separados. La aplicación debe implementar ese comportamiento de alerta; este no es un comparador que lo crea. Verifique que el usuario tenga un siguiente paso seguro, no simplemente que aparezca un texto en rojo. Nunca falsifique un pago completado para demostrar que un pago real funciona.

Vigila los puntos ciegos

Un trabajador de servicio puede interceptar solicitudes antes de que la página de Playwright o el enrutamiento de contexto las vean. La documentación de la red recomienda bloquear a los trabajadores del servicio cuando al enrutamiento nativo le faltan solicitudes esperadas. Elija esa configuración deliberadamente en su configuración de prueba controlada; cambiarlo puede eliminar el comportamiento que de otro modo necesitaría probar.

El enrutamiento del contexto del navegador puede cubrir páginas y ventanas emergentes dentro del contexto, mientras que una regla a nivel de página tiene un alcance más limitado. Decida qué comportamiento necesita en lugar de trasladar cada regla al ámbito más amplio. Mantenga los controladores de ruta y los datos de la prueba dentro de su ciclo de vida.

Los archivos HTTP grabados también pueden reproducir el tráfico, pero las grabaciones pueden contener encabezados, cookies y datos de respuesta confidenciales. Revise y desinfecte una grabación antes de almacenarla. Para este caso de cita simple, una respuesta escrita a mano es más fácil de inspeccionar que un archivo capturado de gran tamaño.

Dale a la evidencia un nombre que sobreviva al tablero.

Utilice un título de prueba, como interfaz de usuario de cotización de entrega, respuesta simulada del proveedor. En las notas de revisión, indique el punto final controlado, la versión del contrato y la verificación del servicio real por separado. Un compañero de equipo no debería necesitar inspeccionar el código de ruta para descubrir que el proveedor estaba ausente.

AnyTest describe la exploración basada en URL y prueba la revisión humana. Aplicar la misma pregunta sobre evidencia a cualquier flujo propuesto: ¿qué dependencias eran reales, cuáles estaban controladas y qué establece un pase? Esta guía no pretende tener una interfaz burlona específica dentro de AnyTest.

Para un equipo pequeño de QA, la recompensa es una ruta de diagnóstico más clara y una cobertura deliberada del estado de falla. Para un conjunto de pruebas propiedad del desarrollador, es lo mismo: mantenga comprobaciones repetibles de la interfaz de usuario, mantenga visible el límite de integración y no permita que una dependencia simulada conveniente se convierta en una promesa mayor de lo que la prueba puede soportar.