Vérifiez le téléchargement, pas seulement le bouton.

Le bouton Exporter répond. Un téléchargement démarre. Le test devient vert. Plus tard, quelqu'un ouvre le fichier et trouve les lignes de la veille, les mauvaises colonnes ou une page de connexion enregistrée avec un nom de feuille de calcul. L'interaction du navigateur a fonctionné, mais pas le résultat utile.

Ce guide crée une vérification des artefacts à partir de la documentation téléchargée de Playwright. L'exemple utilise un petit CSV inventé à partir d'une démo locale. Il ne s'agit pas d'un dossier financier, d'une exportation d'un fournisseur ou d'une affirmation selon laquelle un produit fournit ce format. L'objectif est de connecter le clic à des preuves sur les octets résultants.

Enregistrez l'attente avant l'action

Un téléchargement rapide peut commencer immédiatement après le clic. Commencez par attendre, puis effectuez l'action et attendez la même promesse. Cela maintient l'événement dans le flux de test principal au lieu de laisser un rappel non suivi s'exécuter une fois le scénario terminé.

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

Cet extrait appartient à un test Playwright qui reçoit page et testInfo, avec des attentes importées du package de test. Le chemin de sortie explicite évite de traiter un nom de fichier suggéré comme une destination approuvée. La documentation indique que saveAs attend la fin. Un système de fichiers lu après cette étape examine l'artefact enregistré, pas seulement la promesse de l'interface utilisateur.

Choisissez un contrat de contenu, pas une assertion pratique

Les octets exacts sont appropriés pour cette démo délibérément corrigée. Une véritable exportation peut contenir des horodatages, des identifiants générés ou un ordre de lignes qui change légitimement. Décidez quels champs doivent être stables et analysez le format réel avec une bibliothèque appropriée. Ne rendez pas un test flou en exigeant l'égalité pour des valeurs que le produit n'a jamais promises.

Pour un CSV, le contrat peut exiger des colonnes nommées, l'enregistrement contrôlé attendu et un nombre de lignes valide. Le vrai CSV peut inclure des virgules entre guillemets, des sauts de ligne et des encodages ; une division naïve sur les virgules n'est pas un analyseur général. Pour un PDF, utilisez une vérification appropriée du texte ou de la structure et un examen visuel lorsque la mise en page est importante. Une sauvegarde réussie ne prouve pas que l'un ou l'autre format est valide.

Conservez la validité du format, le contenu commercial et la présentation comme des questions distinctes. Un nom de fichier se terminant par .csv indique ce que l'appelant a suggéré, et non ce que contient le fichier. Un en-tête peut être correct alors que chaque ligne de données est fausse. Un analyseur peut accepter un document dont les pages sont rognées. Sélectionnez les chèques qui correspondent au risque de l'exportation.

Donnez au dossier de test un endroit sûr où vivre

Playwright note que les téléchargements appartenant à un contexte sont supprimés à la fermeture de ce contexte. Conservez un artefact avant le démontage lorsque le test en a besoin plus tard. Utilisez un répertoire de sortie de test contrôlé et indiquez la raison pour laquelle il est conservé. Ne comptez pas sur un chemin de navigateur temporaire qui survivra à la suite.

L'exportation enregistrée peut contenir des éléments plus sensibles qu'une capture d'écran. Testez avec des enregistrements intermédiaires inventés ou approuvés et inspectez les téléchargements en échec avant de les distribuer. La suppression de la capture d'écran ne supprime pas le CSV joint à côté. L'URL de téléchargement peut également contenir des informations d'accès privé ; évitez de le copier dans des notes de débogage publiques.

Lorsqu'une assertion échoue, conservez uniquement les preuves autorisées par la politique de rétention de votre équipe. Enregistrez l'action, l'entrée contrôlée, le résultat de l'analyseur et l'échec du contrat. Une trace générique de clic sur un bouton constitue un contexte utile, mais elle ne peut pas remplacer l'artefact que l'utilisateur reçoit réellement.

Testez délibérément les chemins vides et rejetés

Un bon contrôle d'exportation inclut le comportement attendu en cas d'absence d'enregistrement et en cas de demande rejetée. La bonne réponse peut être un fichier vide avec des en-têtes, un message clair ou aucun téléchargement. C'est une décision de produit à établir avant de rédiger l'assertion. Ne forcez pas chaque état à produire un fichier simplement parce que l'assistant happy-path en attend un.

Utilisez des tests séparés avec des entrées contrôlées. Si l'application signale un échec, vérifiez l'explication et effectuez la prochaine action. Si un fichier inattendu arrive néanmoins, inspectez-le au lieu d'accepter aveuglément l'extension suggérée. Un document d'erreur HTML ne constitue pas une exportation de données réussie.

AnyTest décrit l'exploration basée sur les URL et les tests de bout en bout révisés par des humains. Un réviseur peut demander si un parcours d'exportation proposé vérifie l'artefact ou uniquement le contrôle. Ce guide ne revendique pas d'analyseur de téléchargement ou de fonctionnalité de stockage spécifique dans AnyTest. Pour les équipes disposant d'un temps QA limité, cette limite empêche qu'un clic rassurant ne devienne une fausse promesse sur les données fournies.