Check the download, not just the button.

The Export button responds. A download starts. The test turns green. Later, someone opens the file and finds yesterday's rows, the wrong columns or a sign-in page saved with a spreadsheet name. The browser interaction worked, but the useful outcome did not.

This guide builds an artifact check from Playwright's download documentation. The example uses a tiny invented CSV from a local demo. It is not a financial record, a vendor export or a claim that any product provides this format. The goal is to connect the click to evidence about the resulting bytes.

Register the wait before the action

A fast download can begin immediately after the click. Start waiting first, then perform the action and await the same promise. This keeps the event in the main test flow instead of leaving an untracked callback running after the scenario ends.

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

This snippet belongs inside a Playwright test that receives page and testInfo, with expect imported from the test package. The explicit output path avoids treating a suggested filename as a trusted destination. The documentation says saveAs waits for completion. A filesystem read after that step examines the saved artifact, not merely the UI's promise.

Choose a content contract, not a convenient assertion

Exact bytes are appropriate for this deliberately fixed demo. A real export may contain timestamps, generated identifiers or row ordering that legitimately changes. Decide which fields must be stable and parse the actual format with a suitable library. Do not make a test flaky by demanding equality for values the product never promised.

For a CSV, the contract might require named columns, the expected controlled record and a valid row count. Real CSV can include quoted commas, line breaks and encodings; a naive split on commas is not a general parser. For a PDF, use an appropriate text or structure check and visual review when layout matters. A successful save does not prove either format is valid.

Keep format validity, business content and presentation as separate questions. A filename ending in .csv says what the caller suggested, not what the file contains. A header can be correct while every data row is wrong. A parser can accept a document whose pages are cropped. Select checks that match the risk of the export.

Give the test record a safe place to live

Playwright notes that downloads belonging to a context are deleted when that context closes. Persist an artifact before teardown when the test needs it later. Use a controlled test-output directory and name the reason it is retained. Do not depend on a temporary browser path surviving the suite.

The saved export can contain more sensitive material than a screenshot. Test with invented or approved staging records, and inspect failure uploads before distributing them. Redacting the screenshot does not redact the CSV attached beside it. The download URL may also carry private access information; avoid copying it into public debugging notes.

When an assertion fails, preserve only the evidence your team's retention policy permits. Record the action, controlled input, parser result and failed contract. A generic button-click trace is useful context, but it cannot substitute for the artifact that the user actually receives.

Test the empty and rejected paths deliberately

A good export check includes the expected behavior for no records and for a rejected request. The right answer may be an empty file with headers, a clear message or no download. That is a product decision to establish before writing the assertion. Do not force every state to produce a file just because the happy-path helper expects one.

Use separate tests with controlled inputs. If the application reports failure, check the explanation and safe next action. If an unexpected file still arrives, inspect it instead of blindly accepting the suggested extension. An HTML error document is not a successful data export.

AnyTest describes URL-led exploration and human-reviewed end-to-end tests. A reviewer can ask whether a proposed export journey checks the artifact or only the control. This guide does not claim a specific download parser or storage feature in AnyTest. For teams with limited QA time, that one boundary prevents a reassuring click from becoming a false promise about delivered data.