Verifique la descarga, no solo el botón.

El botón Exportar responde. Se inicia una descarga. La prueba se vuelve verde. Más tarde, alguien abre el archivo y encuentra las filas de ayer, las columnas incorrectas o una página de inicio de sesión guardada con un nombre de hoja de cálculo. La interacción del navegador funcionó, pero el resultado útil no.

Esta guía crea una verificación de artefactos a partir de la documentación de descarga de Playwright. El ejemplo utiliza un pequeño CSV inventado en una demostración local. No es un registro financiero, una exportación de proveedor ni una afirmación de que algún producto proporciona este formato. El objetivo es conectar el clic con evidencia sobre los bytes resultantes.

Registra la espera antes de la acción.

Una descarga rápida puede comenzar inmediatamente después del clic. Primero comience a esperar, luego realice la acción y espere la misma promesa. Esto mantiene el evento en el flujo de prueba principal en lugar de dejar una devolución de llamada sin seguimiento ejecutándose una vez finalizado el escenario.

import { readFile } from 'node:fs/promises';

const pendingDownload = page.waitForEvent('download');
await page.getByRole('button', { name: 'Export demo' }).click();
const download = await pendingDownload;
const output = testInfo.outputPath('demo-export.csv');
await download.saveAs(output);
const text = await readFile(output, 'utf8');
expect(text).toBe('name,status\nDemo task,ready\n');

Este fragmento pertenece dentro de una prueba Playwright que recibe la página y la información de prueba, y se importa desde el paquete de prueba. La ruta de salida explícita evita tratar un nombre de archivo sugerido como un destino confiable. La documentación dice saveAs espera hasta que se complete. Una lectura del sistema de archivos después de ese paso examina el artefacto guardado, no simplemente la promesa de la interfaz de usuario.

Elija un contrato de contenido, no una afirmación conveniente

Los bytes exactos son apropiados para esta demostración deliberadamente arreglada. Una exportación real puede contener marcas de tiempo, identificadores generados u orden de filas que cambia legítimamente. Decida qué campos deben ser estables y analice el formato real con una biblioteca adecuada. No haga que una prueba sea inestable exigiendo igualdad de valores que el producto nunca prometió.

Para un CSV, el contrato puede requerir columnas con nombre, el registro controlado esperado y un recuento de filas válido. El CSV real puede incluir comas entre comillas, saltos de línea y codificaciones; una división ingenua entre comas no es un analizador general. Para un PDF, utilice una verificación de estructura o texto adecuada y una revisión visual cuando el diseño sea importante. Un guardado exitoso no prueba que ninguno de los formatos sea válido.

Mantenga la validez del formato, el contenido comercial y la presentación como preguntas separadas. Un nombre de archivo que termina en .csv dice lo que sugirió la persona que llama, no lo que contiene el archivo. Un encabezado puede ser correcto mientras que todas las filas de datos sean incorrectas. Un analizador puede aceptar un documento cuyas páginas estén recortadas. Seleccione cheques que coincidan con el riesgo de la exportación.

Dale al registro de prueba un lugar seguro para vivir

Playwright señala que las descargas que pertenecen a un contexto se eliminan cuando ese contexto se cierra. Conservar un artefacto antes de su desmontaje cuando la prueba lo necesite más adelante. Utilice un directorio de salida de prueba controlado y mencione el motivo por el que se conserva. No dependa de una ruta temporal del navegador que sobreviva a la suite.

La exportación guardada puede contener material más confidencial que una captura de pantalla. Pruebe con registros de preparación inventados o aprobados e inspeccione las cargas fallidas antes de distribuirlas. Al redactar la captura de pantalla no se redacta el CSV adjunto a ella. La URL de descarga también puede contener información de acceso privado; Evite copiarlo en notas de depuración públicas.

Cuando una afirmación falla, conserve solo la evidencia que permita la política de retención de su equipo. Registre la acción, la entrada controlada, el resultado del analizador y el contrato fallido. Un seguimiento genérico de clic en un botón es un contexto útil, pero no puede sustituir el artefacto que el usuario realmente recibe.

Pruebe deliberadamente las rutas vacías y rechazadas

Una buena verificación de exportación incluye el comportamiento esperado sin registros y con una solicitud rechazada. La respuesta correcta puede ser un archivo vacío con encabezados, un mensaje claro o ninguna descarga. Esa es una decisión de producto que se debe establecer antes de escribir la afirmación. No fuerce a cada estado a producir un archivo sólo porque el asistente de ruta feliz espera uno.

Utilice pruebas separadas con entradas controladas. Si la aplicación informa una falla, verifique la explicación y la siguiente acción segura. Si aún llega un archivo inesperado, inspecciónelo en lugar de aceptar ciegamente la extensión sugerida. Un documento de error HTML no es una exportación de datos exitosa.

AnyTest describe la exploración dirigida por URL y las pruebas de un extremo a otro revisadas por humanos. Un revisor puede preguntar si un viaje de exportación propuesto verifica el artefacto o sólo el control. Esta guía no pretende disponer de un analizador de descargas ni de una función de almacenamiento específicas en AnyTest. Para los equipos con tiempo QA limitado, ese límite evita que un clic tranquilizador se convierta en una falsa promesa sobre los datos entregados.