Fiabiliser les tests de transfert de fichiers dans le navigateur

Les tests automatisés de fichiers dans le navigateur sont fiables lorsque chaque test maîtrise ses entrées et ses sorties, attend le bon signal de fin et vérifie séparément l’application et les octets enregistrés. Pour un envoi, partez d’un fichier synthétique et d’un champ connu, confirmez le nom sélectionné et l’état de validation, puis vérifiez le résultat d’acceptation visible. Pour un téléchargement, déclenchez l’action documentée, attendez l’événement du navigateur, enregistrez l’artefact dans un chemin unique appartenant au test et ne contrôlez que les propriétés utiles. Supprimez les fichiers temporaires que vous avez créés ; un événement local ne prouve ni l’achèvement métier ni la suppression d’un fichier distant.

Cette limite compte, car un transfert implique plusieurs responsables. Le runner possède sa fixture et son chemin local ; le navigateur expose la sélection et le téléchargement ; l’application décide si elle accepte le fichier ; un service peut l’analyser, le traiter, le stocker, le refuser ou le conserver lorsque le navigateur ne l’observe plus. Distinguer ces résultats aide à diagnostiquer une panne sans consulter des fichiers personnels sans rapport ni publier leur contenu dans les journaux. Les guides téléchargement de Playwright, envoi de fichiers et chargement de fichiers Selenium décrivent les mécanismes du framework, pas les garanties de l’application.

Définir le contrat du transfert

Commencez par la question de l’utilisateur : le document attendu est-il disponible, ou l’application a-t-elle accepté le fichier choisi et terminé l’opération demandée ? Traduisez la réponse en étapes observables. Un envoi peut comporter la sélection, la validation côté client, la requête soumise et la confirmation de l’application. Un téléchargement peut comporter l’action, l’événement de transfert, l’artefact local et le changement d’état de l’application. Ne réduisez pas ces étapes à une assertion vague comme « le fichier fonctionne ».

Avant d’ajouter les appels du framework, rédigez le contrat de fixture : fichier synthétique, format et classe de taille, page ou champ utilisé, résultat attendu, worker propriétaire, emplacement de sortie et nettoyage en cas de réussite comme d’échec. Précisez aussi ce que le test ne démontre pas. Enregistrer un rapport ne prouve pas la validation d’une transaction en base, et afficher un nom dans le champ ne prouve pas la fin du traitement distant. Le guide sur les fixtures et l’isolation décrit plus largement la responsabilité des ressources.

Gardez un périmètre public limité. Utilisez une route de test autorisée et un compte synthétique approuvé. N’ouvrez pas le sélecteur de fichiers d’une personne, ne téléversez pas des documents trouvés sur la machine, n’énumérez pas les fichiers du serveur et ne considérez pas un nom comme une autorisation d’en lire le contenu. Si le test a besoin d’un fichier appartenant à l’application, créez-le ou préparez-le via une interface de test documentée et désignez son responsable de suppression. Les données doivent être manifestement synthétiques, non sensibles et adaptées à une courte rétention dans un espace CI à accès restreint.

Définissez la réussite pour le produit, pas uniquement pour le navigateur. Un formulaire peut afficher le nom choisi avant tout envoi. Le navigateur peut émettre un événement de téléchargement alors que le rapport contient une page d’erreur. Choisissez une ou deux vérifications pertinentes : état visible, type de contenu attendu, en-tête stable, identifiant synthétique connu ou empreinte pour une fixture déterministe. Ne comparez pas tous les octets si les dates, identifiants générés ou fins de ligne doivent varier.

Choisir l’API et conserver une fixture d’échec

Utilisez cette petite matrice pour choisir l’API navigateur la plus étroite et le résultat qu’elle peut prouver. L’assertion de l’application reste distincte de l’événement du framework.

Besoin	Playwright	Selenium/WebDriver	Limite de preuve
Affecter un envoi	locator.setInputFiles() ou sélecteur de fichiers	sendKeys() sur <input type="file">	Sélection et validation cliente
Observer un téléchargement	page.waitForEvent('download') avant l’action	Gestion propre au pilote puis chemin maîtrisé	Transfert et contrôle borné
Exercer un rejet	Fixture synthétique avec une propriété modifiée	Même fixture via le champ fichier	Erreur du champ et contrôle réutilisable
Nettoyer	finally supprime le dossier de tentative	finally supprime le dossier de tentative	Propriété locale seulement

Conservez une fixture d’échec copiable près du test. Elle rend un délai d’attente ou un rejet reproductible sans recueillir de document réel :

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 });
}

Le résultat attendu est un rejet associé au champ, puis un contrôle encore utilisable. Un délai de téléchargement utilise le même dossier de tentative, mais conserve le premier délai comme échec principal. Cette vérification porte sur l’observabilité des transferts ; la responsabilité générale des fixtures et les parcours d’accessibilité exigent leurs propres tests.

Rendre les envois déterministes

Préférez l’API de champ fichier du framework à l’automatisation d’une boîte de dialogue système. WebDriver affecte un chemin local à <input type="file"> ; Playwright peut définir les fichiers ou gérer un sélecteur. Ces méthodes ciblent le contrôle explicite de la page sans dépendre du focus de fenêtre, du thème du bureau, de la langue de la boîte de dialogue ou du timing d’une interface native séparée. Elles exigent néanmoins une page autorisée et une fixture maîtrisée. Les API ne remplacent pas la validation ni les règles d’accès de l’application ; n’utilisez un champ masqué que s’il s’agit bien du contrôle du parcours documenté.

Préparez des fixtures immuables. Donnez à chacune un nom de scénario explicite, une extension maîtrisée, un type média connu, une taille limitée et un contenu adapté au cas. Une image valide doit être une petite image connue, pas une image quelconque de la machine simplement renommée en .png. Pour un rejet, faites varier une seule propriété, comme l’extension ou la taille déclarée, afin d’attribuer la réponse. Gardez un petit ensemble réutilisable : les documents réels ajoutent un risque de confidentialité et de maintenance sans renforcer l’assertion.

Vérifiez la sélection avant l’envoi. Confirmez le nom ou le nombre de fichiers affiché et, si nécessaire, le résumé du type ou de la taille. Soumettez ensuite avec l’action habituelle et attendez une réponse produit documentée. Cette séparation aide à localiser le problème : absence de sélection pour la fixture ou le champ, rejet immédiat pour la validation cliente, attente après l’envoi pour le transport ou le traitement. Le retour réussi d’un clic ne prouve pas que le fichier a atteint le service.

Testez la validation comme un contrat, pas comme une collection de textes d’erreur fortuits. Incluez un fichier synthétique valide, un fichier à une limite documentée et un fichier représentatif rejeté uniquement si ces cas comptent pour l’utilisateur. Vérifiez que le champ reste utilisable, que l’erreur est associée au champ et compréhensible, et qu’une correction permet de recommencer. Évitez les textes exacts générés par le navigateur et les messages serveur non spécifiés.

Les métadonnées du fichier ne sont pas fiables. L’extension et le type MIME annoncés par le navigateur peuvent être absents, imprécis ou incohérents volontairement. L’application doit appliquer côté serveur son autorisation, ses limites de taille, l’analyse du format et la validation du contenu. L’automatisation peut confirmer la réponse publique à un cas synthétique incohérent, mais elle ne certifie ni le scanner du serveur, ni les permissions de stockage, ni la chaîne de traitement. Ces propriétés exigent des tests applicatifs et des preuves côté service.

Rendre les téléchargements observables

Commencez l’attente du téléchargement avant de déclencher l’action qui doit le produire. Ainsi, un événement rapide ne survient pas avant l’abonnement du test. L’événement du navigateur marque une frontière utile ; le test peut ensuite enregistrer l’artefact dans un chemin créé pour cette tentative et examiner une propriété minimale. Un dossier par défaut ou un nom fixe dépend de la configuration machine et provoque des collisions en parallèle. Utilisez un nouveau répertoire par worker et tentative, sous une racine temporaire approuvée.

Distinguez le transfert terminé du document correct. Vérifiez le nom suggéré uniquement s’il fait partie de l’expérience visible. Contrôlez un type MIME, une signature, un en-tête ou un champ structuré seulement si cela répond au scénario. Pour un export synthétique déterministe, une empreinte cryptographique permet une comparaison exacte ; pour un rapport dynamique, vérifiez des champs stables et acceptez les variations prévues. N’écrivez pas les contenus complets ni les données base64 dans les journaux CI. Si un contrôle sémantique plus large est nécessaire, utilisez la bibliothèque de format prévue et ne conservez qu’un reçu succinct.

L’événement de téléchargement ne prouve ni la génération du bon enregistrement métier ni l’autorisation de recevoir tous les champs. Vérifiez l’autorisation et le choix du contenu à la frontière documentée de l’application. Pour un rapport, vérifiez la portée synthétique demandée et quelques champs non sensibles. Pour une archive, vérifiez une entrée attendue plutôt que d’extraire des chemins arbitraires. La traversée de chemin, les limites de décompression et le traitement dangereux d’archives relèvent de tests applicatifs spécifiques, pas d’une collecte complète lors d’un test d’interface courant.

Ne faites pas dépendre le succès des préférences de téléchargement de la machine, de son environnement graphique ou du dossier Téléchargements réel d’une personne. Les frameworks gardent parfois la ressource dans un stockage temporaire du navigateur jusqu’à son enregistrement explicite ; le cycle varie selon le framework et sa version. Utilisez l’API publique pertinente et son délai de rétention documenté. Ne copiez l’artefact que vers une destination dont le test est propriétaire, puis fermez la page ou le contexte selon son cycle normal et supprimez la copie dans un bloc finally.

Isoler les artefacts et les workers

Chaque worker a besoin d’un espace d’artefacts privé. Incluez une étiquette stable de scénario, de worker et de tentative, sans nom de compte, courriel ni autre identifiant personnel. Gardez une structure prévisible pour la collecte CI tout en interdisant à deux workers d’écrire le même fichier. Un chemin unique évite l’écrasement, mais ne contrôle pas les permissions de lecture. Configurez séparément l’accès et la rétention CI, puis ne publiez que les éléments utiles au diagnostic.

Considérez les fixtures comme des entrées en lecture seule. Copiez-les dans l’espace d’un test si le scénario doit les modifier ou les renommer. Un worker ne doit jamais écraser une fixture partagée pendant sa lecture par un autre. Pour un téléchargement produit, utilisez un nom atomique ou un nouveau répertoire par tentative et échouez clairement si l’artefact attendu manque. N’acceptez pas silencieusement le fichier d’une tentative précédente parce que son nom correspond.

Les contextes parallèles séparent cookies et stockage du navigateur, mais n’isolent ni le système de fichiers de la machine ni les enregistrements côté serveur. Un contexte neuf n’empêche pas deux tests de demander la même exportation, de modifier le même enregistrement ou de supprimer la même fixture distante. Donnez à chaque worker des données synthétiques propres ou une opération de remise à zéro documentée avec un responsable explicite. Ne sérialisez que la mutation réellement partagée ; une attente supplémentaire n’est pas un verrou fiable.

Limitez les artefacts selon leur sensibilité. Une facture téléchargée, un paquet de diagnostic ou une image fournie peut contenir des données privées même si le fichier a été créé pour un test. Préférez des fixtures synthétiques peu informatives, restreignez l’accès aux fichiers bruts, choisissez une expiration courte et limitez les journaux ordinaires à l’étiquette du scénario, la catégorie, la classe de taille, le résultat et l’état du nettoyage. Une capture d’écran peut révéler davantage qu’un reçu ; utilisez-la seulement sur une page synthétique autorisée lorsqu’elle aide au diagnostic.

Nettoyer et recommencer prudemment

Le nettoyage suit la propriété. Le test qui crée un dossier temporaire le supprime ; le propriétaire du contexte ferme le contexte ; l’application ou le service supprime un objet distant par son interface prise en charge. Fermer un contexte ne supprime pas une copie téléchargée, n’annule pas un travail serveur et n’efface pas un enregistrement envoyé. Utilisez finally pour que réussite, assertion échouée et délai dépassé suivent le même chemin. Si le nettoyage échoue, signalez-le avec le problème initial sans masquer l’assertion ni afficher une réussite trompeuse.

Rendez le nettoyage idempotent. Un délai peut survenir après l’écriture du fichier mais avant l’enregistrement du résultat, ou un mécanisme de sécurité peut fermer un contexte déjà fermé. Vérifiez le chemin possédé et l’état de la ressource, ne nettoyez que ce que cette tentative a créé et signalez le nettoyage incomplet s’il n’est pas vérifiable. Ne parcourez jamais un large dossier machine pour supprimer des fichiers sur la seule base de leur nom ou extension. La frontière de nettoyage doit être plus étroite que la racine des artefacts lorsque c’est possible.

Une nouvelle tentative est un essai distinct doté d’un dossier de sortie privé. Avant de répéter un envoi ou de demander une autre exportation, déterminez si l’action est en lecture seule, idempotente ou consultable sans risque grâce à un identifiant de scénario. La première requête a peut-être atteint le service même si le navigateur a expiré avant d’afficher une réponse. Consultez un état applicatif ou un résultat existant lorsque le produit le prévoit ; sinon, signalez l’incertitude et laissez le responsable du test décider. Ne transformez pas une mutation ambiguë en doublon automatique.

Conservez le premier échec comme résultat principal. Si le téléchargement expire puis que le nettoyage échoue, le reçu doit signaler les deux problèmes. Incluez les versions du framework et du navigateur, l’étiquette du scénario, la frontière d’action, le signal attendu, la présence de l’artefact et l’état du nettoyage. Excluez cookies, en-têtes d’autorisation, texte intégral de page, octets du fichier et noms personnels. Ces éléments suffisent à orienter le diagnostic sans transformer le rapport en second stockage de données.

Examiner la frontière applicative

La réussite d’un envoi a plusieurs sens : le navigateur a sélectionné le fichier, l’application a accepté la requête, le traitement asynchrone est terminé ou l’objet stocké est disponible. Choisissez le sens correspondant au besoin utilisateur et vérifiez-le à la bonne frontière. Un message « en file d’attente » prouve l’entrée dans une file, pas la fin d’une analyse antivirus. Une notification verte prouve l’affichage d’une réponse, pas la possibilité de télécharger l’objet plus tard. Si la persistance compte, utilisez une vue ultérieure ou une API documentée pour les tests.

Un téléchargement comporte lui aussi plusieurs niveaux. Le lien peut exister tout en visant le mauvais périmètre ; le navigateur peut terminer le transfert d’une page d’accès refusé ; le fichier peut être enregistré alors que le serveur signale une erreur. Associez une action visible à une vérification limitée de l’artefact et, si nécessaire, à une assertion applicative autorisée. Ne collectez pas de requêtes sans rapport et ne déduisez pas de données de compte cachées par inspection réseau. Limitez l’instrumentation à la requête ou au résultat nécessaire.

Gardez les tests de bout en bout proportionnés. Les contrôles de nom, d’analyse MIME, de limite de taille et de validation serveur sont souvent plus rapides et plus précis au niveau composant ou API. Réservez le navigateur au parcours vécu : choisir un fichier, voir une validation accessible, lancer un téléchargement et recevoir un résultat clair. Une suite plus petite est plus facile à diagnostiquer et risque moins de conserver des artefacts sensibles. Le guide de débogage des traces explique comment limiter les diagnostics facultatifs.

Après une mise à jour du navigateur ou du framework, rejouez sélection, annulation, envoi valide, envoi refusé, téléchargement terminé, noms d’artefacts parallèles et nettoyage après échec. Comparez le résultat visible et le comportement documenté de l’API, pas les délais accidentels ou les chemins internes temporaires. Consignez les versions avec le résultat. Si une API change, mettez à jour la fixture et son contrat de propriété ; n’ajoutez pas une attente large ou des reprises pour masquer la différence.

Capacité et limite de BotBrowser

BotBrowser fournit des BrowserContexts isolés avec un état de session séparé géré par le navigateur pour répéter des contrôles autorisés de parcours synthétiques d’envoi et de téléchargement. Une équipe peut démarrer un scénario connu sans réutiliser les cookies ou le stockage d’un autre contexte, puis comparer la sélection, la validation et l’état d’achèvement visibles. Cette capacité est utile lorsque la question concerne un parcours authentifié et que l’état initial doit être maîtrisé. BotBrowser ne contrôle pas le dossier de téléchargement du système, ne valide pas le traitement serveur du fichier, ne remplace pas la gestion des événements du framework ni la gestion sûre des fichiers temporaires et ne garantit pas la suppression distante. Consultez l’isolation multi-comptes BotBrowser et le cycle de téléchargement documenté par Playwright.

L’isolation d’un BrowserContext ne possède pas un dossier système et ne détermine pas si le serveur a accepté, analysé, stocké ou supprimé un fichier. Le runner doit employer des fichiers synthétiques approuvés, des chemins temporaires privés, vérifier le résultat applicatif, restreindre les artefacts conservés et appeler l’interface de nettoyage du service si nécessaire. Un contexte propre ne renseigne que sur l’état géré par le navigateur.

Dans le reçu opérationnel, consignez versions du navigateur et du framework, étiquette du scénario, catégorie d’entrée synthétique, propriétaire du chemin de sortie, signal attendu, résultat observé et état du nettoyage. N’incluez pas de fichiers bruts dans les journaux habituels ; conservez-les uniquement si un diagnostic autorisé l’exige. Précisez si le test a observé la sélection, le transfert, l’acceptation applicative ou la disponibilité ultérieure : ce sont des faits distincts. Si un résultat serveur compte, utilisez un signal applicatif documenté au lieu d’affirmer que l’événement navigateur l’a prouvé.

Sources

• Playwright : téléchargements
• Playwright : envoi de fichiers
• Selenium : envoi de fichiers
• MDN : API File
• BotBrowser : isolation multi-comptes