Überprüfen Sie den Download, nicht nur die Schaltfläche.

Die Schaltfläche „Exportieren" reagiert. Ein Download startet. Der Test wird grün. Später öffnet jemand die Datei und findet die Zeilen von gestern, die falschen Spalten oder eine Anmeldeseite, die mit einem Tabellennamen gespeichert wurde. Die Browser-Interaktion funktionierte, das nützliche Ergebnis jedoch nicht.

Diese Anleitung erstellt eine Artefaktprüfung aus Playwrights Download-Dokumentation. Das Beispiel verwendet eine kleine erfundene CSV-Datei aus einer lokalen Demo. Es handelt sich nicht um eine Finanzaufzeichnung, keinen Lieferantenexport oder um die Behauptung, dass irgendein Produkt dieses Format bereitstellt. Das Ziel besteht darin, den Klick mit Beweisen über die resultierenden Bytes zu verknüpfen.

Registrieren Sie die Wartezeit vor der Aktion

Ein schneller Download kann direkt nach dem Klick beginnen. Beginnen Sie zunächst mit dem Warten, führen Sie dann die Aktion aus und warten Sie auf das gleiche Versprechen. Dadurch bleibt das Ereignis im Haupttestablauf, anstatt dass nach Ende des Szenarios ein nicht verfolgter Rückruf ausgeführt wird.

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

Dieses Snippet gehört zu einem Playwright-Test, der Seite und TestInfo empfängt, wobei Expect aus dem Testpaket importiert wird. Durch den expliziten Ausgabepfad wird vermieden, dass ein vorgeschlagener Dateiname als vertrauenswürdiges Ziel behandelt wird. In der Dokumentation heißt es, dass saveAs auf den Abschluss wartet. Ein nach diesem Schritt gelesenes Dateisystem untersucht das gespeicherte Artefakt und nicht nur das Versprechen der Benutzeroberfläche.

Wählen Sie einen Inhaltsvertrag, keine bequeme Behauptung

Für diese bewusst festgelegte Demo sind genaue Bytes geeignet. Ein echter Export kann Zeitstempel, generierte Kennungen oder Zeilenreihenfolgen enthalten, die sich rechtmäßig ändern. Entscheiden Sie, welche Felder stabil sein müssen, und analysieren Sie das tatsächliche Format mit einer geeigneten Bibliothek. Machen Sie einen Test nicht unzuverlässig, indem Sie Gleichheit für Werte fordern, die das Produkt nie versprochen hat.

Für eine CSV erfordert der Vertrag möglicherweise benannte Spalten, den erwarteten kontrollierten Datensatz und eine gültige Zeilenanzahl. Echte CSV-Dateien können Anführungszeichen, Zeilenumbrüche und Kodierungen enthalten. Eine naive Aufteilung durch Kommas ist kein allgemeiner Parser. Verwenden Sie für ein PDF eine geeignete Text- oder Strukturprüfung und eine visuelle Überprüfung, wenn es auf das Layout ankommt. Eine erfolgreiche Speicherung beweist nicht, dass eines der beiden Formate gültig ist.

Behalten Sie Formatgültigkeit, Geschäftsinhalt und Präsentation als separate Fragen bei. Ein Dateiname mit der Endung „.csv" sagt aus, was der Aufrufer vorgeschlagen hat, und nicht, was die Datei enthält. Ein Header kann korrekt sein, während jede Datenzeile falsch ist. Ein Parser kann ein Dokument akzeptieren, dessen Seiten beschnitten sind. Wählen Sie Prüfungen aus, die dem Risiko des Exports entsprechen.

Geben Sie dem Testprotokoll einen sicheren Ort zum Aufbewahren

Playwright weist darauf hin, dass Downloads, die zu einem Kontext gehören, gelöscht werden, wenn dieser Kontext geschlossen wird. Behalten Sie ein Artefakt vor dem Abbau bei, wenn der Test es später benötigt. Verwenden Sie ein kontrolliertes Testausgabeverzeichnis und benennen Sie den Grund für die Aufbewahrung. Verlassen Sie sich nicht darauf, dass ein temporärer Browserpfad die Suite überdauert.

Der gespeicherte Export kann sensibleres Material enthalten als ein Screenshot. Testen Sie mit erfundenen oder genehmigten Staging-Datensätzen und überprüfen Sie fehlerhafte Uploads, bevor Sie sie verteilen. Durch das Schwärzen des Screenshots wird die daneben angehängte CSV-Datei nicht geschwärzt. Die Download-URL kann auch private Zugangsinformationen enthalten; Vermeiden Sie es, es in öffentliche Debugging-Notizen zu kopieren.

Wenn eine Behauptung fehlschlägt, bewahren Sie nur die Beweise auf, die die Aufbewahrungsrichtlinie Ihres Teams zulässt. Zeichnen Sie die Aktion, die kontrollierte Eingabe, das Parser-Ergebnis und den fehlgeschlagenen Vertrag auf. Ein allgemeiner Button-Click-Trace ist ein nützlicher Kontext, kann jedoch nicht das Artefakt ersetzen, das der Benutzer tatsächlich erhält.

Testen Sie die leeren und abgelehnten Pfade bewusst

Eine gute Exportprüfung umfasst das erwartete Verhalten bei fehlenden Datensätzen und bei einer abgelehnten Anfrage. Die richtige Antwort könnte eine leere Datei mit Headern, eine klare Nachricht oder kein Download sein. Dies ist eine Produktentscheidung, die vor dem Verfassen der Behauptung getroffen werden muss. Zwingen Sie nicht jeden Staat, eine Datei zu erstellen, nur weil der Happy-Path-Helfer eine erwartet.

Verwenden Sie separate Tests mit kontrollierten Eingaben. Wenn die Anwendung einen Fehler meldet, überprüfen Sie die Erklärung und achten Sie auf die nächste Aktion. Wenn dennoch eine unerwartete Datei eintrifft, überprüfen Sie sie, anstatt die vorgeschlagene Erweiterung blind zu akzeptieren. Ein HTML-Fehlerdokument ist kein erfolgreicher Datenexport.

AnyTest beschreibt URL-gesteuerte Exploration und von Menschen überprüfte End-to-End-Tests. Ein Prüfer kann fragen, ob eine vorgeschlagene Exportreise das Artefakt prüft oder nur die Kontrolle. Dieses Handbuch erhebt keinen Anspruch auf eine bestimmte Download-Parser- oder Speicherfunktion in AnyTest. Für Teams mit begrenzter QA-Zeit verhindert diese eine Grenze, dass ein beruhigender Klick zu einer falschen Versprechung über gelieferte Daten wird.