Pruebas limpias de carga y descarga en la automatización del navegador

Las pruebas de archivos con automatización del navegador son fiables cuando cada prueba es propietaria de sus entradas y salidas, espera la señal correcta de finalización y evalúa la aplicación por separado de los bytes guardados. Para una carga, comienza con un archivo sintético y un control conocido, confirma el nombre elegido y la validación, y después comprueba la aceptación visible de la aplicación. Para una descarga, activa la acción documentada, espera el evento del navegador, guarda el artefacto en una ruta única de la prueba y revisa solo las propiedades necesarias. Elimina los temporales que te pertenecen; un evento local no demuestra que haya terminado una operación comercial ni que se haya borrado un archivo remoto.

Este límite importa porque una transferencia tiene varios responsables. El ejecutor de pruebas posee el fixture y la ruta local; el navegador muestra la selección y la descarga; la aplicación decide si acepta el archivo; y un servicio puede analizarlo, procesarlo, almacenarlo, rechazarlo o conservarlo después de que el navegador deje de observar. Separar esos resultados permite diagnosticar un fallo sin leer archivos personales ajenos ni volcar contenidos en registros. Las guías de descargas de Playwright, carga de archivos y carga en Selenium describen mecanismos del framework, no garantías de la aplicación.

Define el contrato de transferencia

Empieza por la pregunta de la persona usuaria: ¿está disponible el documento esperado o aceptó la aplicación el archivo elegido y completó la operación solicitada? Convierte la respuesta en puntos de control observables. Una carga puede incluir selección, validación en el cliente, envío y confirmación de la aplicación. Una descarga puede incluir acción, evento de transferencia, artefacto local y cambio de estado de la aplicación. No reduzcas todo a una aserción imprecisa como «el archivo funcionó».

Antes de añadir llamadas del framework, describe el contrato del fixture: archivo sintético, formato y categoría de tamaño, página o control, resultado esperado, worker propietario, ruta de salida y limpieza tanto en éxito como en error. Indica también qué no demuestra la prueba. Guardar un informe no prueba que se confirmara una transacción de base de datos; mostrar un nombre en el control tampoco demuestra que terminara el procesamiento remoto. La guía de fixtures y aislamiento desarrolla la propiedad de recursos con más detalle.

Mantén acotado el límite público del escenario. Usa una ruta de prueba autorizada y una cuenta sintética aprobada. No abras el selector de archivos de una persona, no cargues documentos encontrados en el equipo, no enumeres archivos del servidor ni interpretes un nombre como permiso para inspeccionar su contenido. Si la prueba necesita un archivo de la aplicación, créalo o aprovisiónalo mediante una interfaz de prueba documentada e identifica quién lo elimina. Los datos deben ser claramente sintéticos, no sensibles y seguros para una retención breve en un entorno de integración continua restringido.

Define el éxito para el producto, no solo para el navegador. Un formulario puede mostrar el nombre elegido antes de enviar nada. El navegador puede emitir un evento de descarga aunque el informe contenga una página de error. Escoge una o dos comprobaciones útiles: estado visible, tipo de contenido esperado, encabezado estable, identificador sintético conocido o resumen criptográfico para un fixture determinista. No compares todos los bytes cuando se espera que varíen las fechas, los identificadores generados o los finales de línea.

Elige la API y conserva un fixture de fallo

Usa esta matriz breve para elegir la API de navegador más acotada y el resultado que puede demostrar. La aserción de la aplicación sigue separada del evento del framework.

Necesidad	Playwright	Selenium/WebDriver	Límite de la evidencia
Asignar una carga	locator.setInputFiles() o selector de archivos	sendKeys() en <input type="file">	Selección y validación del cliente
Observar una descarga	page.waitForEvent('download') antes de la acción	Gestión de descarga del controlador y ruta propia	Transferencia y comprobación acotada
Probar un rechazo	Fixture sintético con una propiedad cambiada	El mismo fixture mediante el campo	Error del campo y control reutilizable
Limpiar	finally elimina el directorio del intento	finally elimina el directorio del intento	Solo propiedad local

Conserva un fixture de fallo copiable junto a la prueba. Hace reproducible un tiempo de espera o rechazo sin recoger un documento real:

const attemptDir = await fs.mkdtemp(path.join(os.tmpdir(), 'file-transfer-'));
try {
  await page.locator('input[type=file]').setInputFiles('fixtures/rejected-type.txt');
  await expect(page.getByRole('alert')).toContainText('file type');
} finally {
  await fs.rm(attemptDir, { recursive: true, force: true });
}

El resultado esperado del fixture es un rechazo asociado al campo y un control que sigue utilizable. Un tiempo de espera de descarga usa el mismo directorio propio, pero conserva el primer tiempo de espera como fallo principal. Esta comprobación se centra en observar transferencias; la propiedad general de fixtures y los recorridos de accesibilidad requieren sus propias pruebas.

Haz deterministas las cargas

Prefiere la API de archivos del framework a automatizar cuadros de diálogo del sistema operativo. WebDriver asigna una ruta local a <input type="file">; Playwright puede establecer archivos o gestionar un selector. Así se usa el control explícito de la página sin depender del foco de ventana, el tema del escritorio, el idioma del diálogo ni el tiempo de una interfaz nativa separada. Aun así, hace falta una página autorizada y un fixture propio. Las APIs no sustituyen la validación ni las reglas de acceso de la aplicación; usa un control oculto únicamente cuando sea el control real del flujo documentado.

Prepara fixtures inmutables. Asigna a cada uno un nombre de escenario, extensión controlada, tipo de medio conocido, tamaño acotado y contenido diseñado para el caso. Una imagen válida debe ser una imagen pequeña conocida, no una imagen cualquiera del equipo renombrada como .png. Para un rechazo, cambia una sola propiedad, como la extensión o el tamaño declarado, para poder atribuir la respuesta. Conserva un conjunto pequeño y reutilizable: acumular documentos reales añade riesgo de privacidad y mantenimiento sin reforzar la aserción.

Comprueba la selección antes del envío. Confirma el nombre o el número de archivos y, cuando corresponda, el resumen de tamaño o tipo. Después envía con la acción habitual y espera una respuesta del producto documentada. La separación localiza mejor el defecto: si no hay selección, revisa fixture o control; el rechazo inmediato apunta a validación del cliente; un resultado pendiente tras el envío puede corresponder al transporte o al procesamiento. Que el clic termine no demuestra que el archivo llegara al servicio.

Prueba la validación como un contrato, no como una lista de textos de error accidentales. Incluye un archivo sintético válido, uno en un límite documentado y un rechazo representativo solo si esos casos importan. Comprueba que el control siga disponible, que el error esté asociado al campo y sea comprensible, y que corregir la entrada permita reintentar. Evita depender de textos exactos generados por el navegador o de mensajes no especificados del servidor.

Los metadatos del archivo no son confiables. La extensión y el tipo MIME que informa el navegador pueden faltar, ser imprecisos o no coincidir intencionadamente. La aplicación debe aplicar autorización, límites de tamaño, análisis del formato y validación de contenido en el servidor. La automatización puede confirmar la respuesta pública ante un caso sintético incoherente, pero no certificar el antivirus, los permisos de almacenamiento ni el procesamiento del servicio. Esas propiedades requieren pruebas de aplicación y evidencia del servicio.

Haz observables las descargas

Empieza a esperar la descarga antes de activar la acción que la provoca. Así, un evento rápido no ocurre antes de que la prueba se suscriba. El evento del navegador marca un límite útil de transferencia; después se puede guardar el artefacto en una ruta creada para este intento y revisar una propiedad mínima. Una carpeta predeterminada o un nombre compartido vincula la prueba a la configuración del equipo y provoca colisiones en paralelo. Usa un directorio nuevo por worker e intento, dentro de una raíz temporal aprobada.

Distingue entre transferencia completada y documento correcto. Comprueba el nombre sugerido solo si forma parte de la experiencia visible. Revisa el tipo MIME, una firma, un encabezado o un campo estructurado únicamente si responde al escenario. Para una exportación sintética determinista, un resumen criptográfico permite una comparación exacta; en informes dinámicos, verifica campos estables y admite variaciones esperadas. No escribas contenidos completos ni datos base64 en los registros de CI. Si hace falta un análisis semántico amplio, usa la biblioteca de formato admitida y conserva solo un recibo breve.

El evento de descarga no demuestra que la aplicación generara el registro comercial correcto ni que la persona estuviera autorizada a recibir todos los campos. Verifica autorización y selección de contenido en el límite documentado de la aplicación. Para un informe, comprueba el ámbito sintético elegido y unos pocos campos no sensibles. Para un archivo comprimido, verifica una entrada esperada en vez de extraer rutas arbitrarias. Los riesgos de rutas, límites de descompresión y manejo de archivos pertenecen a pruebas específicas de la aplicación, no justifican volcar datos en una ejecución de interfaz rutinaria.

No hagas depender el éxito de las preferencias de descarga del equipo, del entorno gráfico ni de la carpeta real de descargas de una persona. Algunos frameworks mantienen temporalmente las descargas en el navegador hasta que la prueba las guarda; los detalles dependen del framework y su versión. Usa la API pública correspondiente y comprueba su límite de retención documentado. Copia el artefacto solo a un destino propio; después cierra la página o el contexto con su ciclo de vida normal y elimina la copia en una ruta finally.

Aísla artefactos y workers paralelos

Cada worker necesita un espacio de artefactos privado. Incluye una etiqueta estable de escenario, worker e intento, pero evita nombres de cuenta, correos u otros identificadores personales. Mantén una estructura predecible para que CI recoja los resultados, sin permitir que dos workers escriban el mismo archivo. Una ruta única evita sobrescrituras, pero no controla quién puede leerla. Configura por separado los permisos y la retención de CI, y publica solo los artefactos necesarios para diagnosticar.

Trata los fixtures como entradas de solo lectura. Cópialos al espacio de una prueba si el escenario debe modificarlos o cambiarles el nombre. No permitas que un worker sobrescriba un fixture compartido mientras otro lo lee. Para descargas generadas, usa nombres atómicos o una carpeta nueva por intento, y falla claramente si falta el artefacto. No aceptes en silencio el archivo de un intento anterior porque coincida el nombre.

Los contextos paralelos separan cookies y almacenamiento del navegador, pero no aíslan el sistema de archivos del equipo ni los registros del servidor. Un contexto nuevo no impide que dos pruebas pidan la misma exportación, usen el mismo registro de carga o compitan por eliminar un fixture remoto. Asigna datos sintéticos diferentes o usa una operación de reinicio documentada con un responsable explícito. Serializa solo la mutación compartida que lo requiera; una espera adicional no es un bloqueo fiable.

Limita los artefactos según su sensibilidad. Una factura descargada, un paquete de diagnóstico o una imagen aportada por una persona pueden contener datos privados incluso si se generaron durante una prueba. Prefiere fixtures sintéticos con poca información, restringe el acceso a los archivos originales, fija una caducidad breve y limita los registros habituales a la etiqueta del escenario, categoría, tamaño aproximado, resultado y limpieza. Una captura de pantalla puede revelar más que un recibo; úsala solo en una página sintética autorizada cuando ayude al diagnóstico.

Limpia y reintenta con seguridad

La limpieza sigue a la propiedad. La prueba que crea el directorio temporal lo elimina; el propietario del contexto lo cierra; y la aplicación o el servicio elimina el objeto remoto mediante su interfaz admitida. Cerrar un contexto no borra una descarga copiada, cancela un trabajo del servidor ni elimina un registro cargado. Usa finally para que errores y tiempos de espera recorran la misma ruta. Si falla la limpieza, informa de ello junto con el error original, sin ocultar la aserción ni mostrar un éxito engañoso.

Haz que la limpieza sea idempotente. Puede agotarse el tiempo después de escribir un archivo pero antes de registrar el éxito, o un mecanismo de seguridad puede cerrar un contexto ya cerrado. Comprueba la ruta propia y el estado de recursos, limpia solo lo creado por este intento y registra la limpieza incompleta si no se puede confirmar. Nunca recorras un directorio amplio del equipo para borrar archivos por su nombre o extensión. El límite de limpieza debe ser más estrecho que la raíz de artefactos siempre que sea posible.

Un reintento es un intento nuevo con un directorio de salida propio. Antes de repetir una carga o solicitar otra exportación, determina si la acción es de lectura, idempotente o consultable sin riesgo mediante un identificador del escenario. La primera petición pudo llegar al servicio aunque el navegador agotara el tiempo antes de mostrar la respuesta. Consulta el estado de la aplicación o un resultado visible existente cuando el producto lo permita; si no, informa del resultado incierto y deja que la persona responsable decida. No conviertas una mutación ambigua en un duplicado automático.

Conserva el primer fallo como resultado principal. Si la descarga agotó el tiempo y luego falla la limpieza, el recibo debe nombrar ambos problemas. Incluye versiones de framework y navegador, etiqueta del escenario, límite de acción, señal esperada, presencia o ausencia del artefacto y estado de limpieza. Excluye cookies, cabeceras de autorización, texto completo, bytes del archivo y nombres personales. Esta evidencia permite asignar el problema sin crear otro almacén de datos en los informes.

Revisa el límite de la aplicación

El éxito de una carga puede significar varias cosas: el navegador eligió el archivo, la aplicación aceptó la petición, terminó el procesamiento asíncrono o el objeto almacenado quedó disponible para otras personas. Escoge el significado de la necesidad del usuario y compruébalo en el límite correcto. Un mensaje «en cola» demuestra aceptación en una cola, no que acabó el análisis antivirus. Un aviso verde demuestra que se mostró una respuesta, no que el objeto pueda descargarse más tarde. Si importa la persistencia, usa una vista posterior o una API de aplicación documentada para pruebas.

Una descarga también tiene capas distintas. El enlace puede existir y apuntar al ámbito equivocado; el navegador puede completar la transferencia de una página de acceso denegado; el archivo puede guardarse mientras el servidor registra un error. Combina la acción visible con una comprobación acotada del artefacto y, si hace falta, otra aserción autorizada de la aplicación. No recopiles peticiones ajenas ni infieras datos ocultos de la cuenta mediante inspección de red. Limita la instrumentación a la petición o el resultado necesario.

Mantén las pruebas de extremo a extremo proporcionales. Los casos de nombre, análisis MIME, límites de tamaño y validación del servidor suelen ser más rápidos y precisos como pruebas de componente o API. Reserva el navegador para la experiencia: seleccionar un archivo, ver un error accesible, iniciar una descarga y recibir una confirmación o un fallo claro. Una suite pequeña es más fácil de diagnosticar y tiene menos probabilidades de retener artefactos sensibles. La guía de depuración de trazas explica cómo limitar los diagnósticos opcionales.

Al actualizar el navegador o el framework, repite la selección, cancelación, carga válida, carga rechazada, descarga completada, nombres paralelos y limpieza ante fallos. Compara el resultado visible y el comportamiento documentado de la API, no el tiempo incidental ni rutas internas temporales. Registra las versiones en cada resultado. Si cambia una API, actualiza el fixture y su contrato de propiedad; no añadas una espera amplia ni más reintentos para ocultar la diferencia.

Capacidad y límite de BotBrowser

BotBrowser proporciona BrowserContexts aislados con estado de sesión separado y administrado por el navegador para repetir comprobaciones autorizadas de flujos sintéticos de carga y descarga. El equipo puede iniciar un escenario conocido sin reutilizar cookies ni almacenamiento de otro contexto, y comparar la selección, validación y confirmación visibles. Resulta útil cuando la pregunta de prueba trata un flujo autenticado y hay que controlar el estado inicial. BotBrowser no controla el destino de descarga del sistema operativo, no valida el procesamiento del archivo en el servidor, no sustituye la gestión de eventos del framework ni la administración segura de temporales y no garantiza el borrado remoto. Consulta el aislamiento multi-cuenta de BotBrowser junto con el ciclo de descarga documentado por Playwright.

El aislamiento del BrowserContext no es propietario de una carpeta del equipo ni determina si el servidor aceptó, analizó, guardó o eliminó un archivo. El ejecutor debe usar archivos sintéticos aprobados, rutas temporales privadas, comprobar el resultado de la aplicación, restringir los artefactos retenidos e invocar la limpieza admitida por el servicio cuando corresponda. Un contexto limpio solo informa del estado administrado por el navegador.

En el recibo operativo registra versión del navegador y framework, etiqueta del escenario, categoría de entrada sintética, propietario de la ruta de salida, señal esperada, resultado observado y estado de limpieza. No incluyas archivos originales en los registros habituales; consérvalos solo si un diagnóstico autorizado los necesita. Indica si la prueba observó selección, transferencia, aceptación de la aplicación o disponibilidad posterior: son hechos diferentes. Si importa un resultado del servicio, usa una señal documentada de la aplicación en vez de afirmar que lo probó el evento del navegador.

Fuentes

• Playwright: descargas
• Playwright: cargar archivos
• Selenium: carga de archivos
• MDN: API File
• BotBrowser: aislamiento multi-cuenta