Pruebe el contrato de carga, no la ruta del archivo.

Se abre un selector de archivos, la prueba selecciona un archivo y la suite declara que la carga se completó. La aplicación solo ha recibido la selección de entrada. Es posible que aún rechace el formato, falle la validación o nunca termine el procesamiento. Un paso de selección verde es un resultado más limitado que un documento cargado utilizable.

Esta guía utiliza la documentación de entrada de Playwright para crear un pequeño archivo de texto local. El archivo contiene contenido inventado. No es un archivo adjunto de cliente, un documento de identidad o un ejemplo de producto. Separamos el contrato de entrada del navegador de cualquier procesamiento que realice la aplicación posteriormente.

Dale al dispositivo una identidad legible

Un dispositivo de prueba debe indicar su nombre, tipo MIME y contenido. Para un pequeño ejemplo de texto, una carga útil en memoria es más fácil de revisar que un binario inexplicable en un repositorio. Utilice datos realistas y válidos para su producto, pero evite documentos fuente privados cuando un espécimen controlado responda la pregunta.

await page.getByLabel('Demo attachment').setInputFiles({
  name: 'demo-note.txt',
  mimeType: 'text/plain',
  buffer: Buffer.from('Invented demo note\n', 'utf8')
});
await expect(page.getByRole('status')).toHaveText('Selected: demo-note.txt');

El fragmento asume una entrada de archivo accesible y un comportamiento de interfaz de usuario local que informa el nombre de archivo seleccionado. La afirmación establece ese comportamiento, no un almacenamiento exitoso en el servidor. Mantenga ese límite en el título de la prueba y la figura explicativa.

Playwright documenta rutas, múltiples archivos, objetos de carga útil y borra la selección a través de setInputFiles. Seleccione la forma de entrada más pequeña que coincida con el caso. Una prueba de varios archivos necesita requisitos sobre ordenamiento, límites y errores individuales; no es simplemente la misma comprobación del camino feliz repetida con más nombres.

Utilice un evento de selección solo cuando sea el límite necesario

Algunas interfaces crean la entrada dinámicamente después de hacer clic en un botón. La guía de entrada describe cómo esperar el evento del selector de archivos antes de la acción y luego llamar a setFiles en el selector devuelto. Coloque el evento en espera primero para que un selector rápido siga conectado al control iniciador.

const pendingChooser = page.waitForEvent('filechooser');
await page.getByRole('button', { name: 'Choose demo file' }).click();
const chooser = await pendingChooser;
await chooser.setFiles({
  name: 'demo-note.txt',
  mimeType: 'text/plain',
  buffer: Buffer.from('Invented demo note\n', 'utf8')
});

Estos son enfoques de selección alternativos para diferentes interfaces, no dos pasos requeridos en una carga. No automatice un diálogo de sistema operativo nativo mediante coordenadas de pantalla adivinadas cuando la entrada documentada o el límite del selector pueden expresar la acción directamente.

La selección, la aceptación y el procesamiento son estados separados

Después de la selección, la aplicación puede inspeccionar el archivo, enviarlo a un servidor y ejecutar un procesador en segundo plano. Escriba el estado esperado para cada capa relevante. El mensaje de aceptación de cara al usuario debe significar lo que dice. Si el procesamiento aún está pendiente, la prueba no debe etiquetar toda la característica como completa.

Para un proceso de carga real, utilice el almacenamiento provisional aprobado y verifique el registro controlado final a través de la evidencia respaldada por el producto. Compruebe que esté disponible el documento correcto, no sólo que haya desaparecido una ruleta. No cargue pruebas inventadas en la carpeta de un cliente en vivo simplemente porque la interfaz de usuario lo hace fácil.

Un nombre de archivo y un tipo MIME son entradas, no pruebas independientes del contenido del archivo. Una carga útil de texto denominada image.png no es una imagen válida. Elija muestras deliberadamente inválidas cuando pruebe el rechazo y muestras válidas cuando pruebe la aceptación. Explique qué contrato debe ejercer cada ejemplar.

Mantenga los casos no válidos pequeños y útiles

El producto puede rechazar un formato no compatible, una entrada de gran tamaño, un archivo vacío o un duplicado. Establezca la política esperada del equipo de aplicación antes de escribir estas afirmaciones. No invente un tamaño máximo ni asuma que un atributo de aceptación del navegador es la regla de seguridad completa.

Verifique la explicación y la siguiente acción segura para un archivo rechazado. Un usuario debería poder elegir otro archivo o eliminar la selección si ese es el diseño deseado. La limpieza de pruebas también es importante: una carga provisional aceptada puede permanecer después de que se cierre el navegador, así que organice la eliminación del registro a través de una ruta aprobada.

Mantenga los accesorios y los artefactos de falla resultantes bajo una revisión de privacidad. Los pequeños insumos inventados son más fáciles de inspeccionar y más seguros de distribuir que los documentos reales capturados. Las capturas de pantalla y los seguimientos pueden revelar nombres de archivos seleccionados incluso cuando los bytes del archivo no están adjuntos.

AnyTest describe a los agentes que exploran una aplicación web y crean pruebas de un extremo a otro para revisión humana. Utilice estos límites para revisar cualquier recorrido de archivo propuesto: seleccionado, aceptado, procesado y disponible. Esta guía no afirma una interfaz de carga AnyTest particular ni una integración de validación. El beneficio es un contrato de artefacto claro que evita que una acción de entrada exitosa se convierta en una promesa falsa sobre los resultados del servidor.