> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/planning-and-decision-guides/chart-and-download-assertion-evaluation.md). # Chart & Download Assertion Evaluation Design evidence-led tests for chart values and downloaded files, separating business correctness from click success and unsupported automation. > **Editorial owner:** ContextQA Documentation · **Last updated:** September 12, 2026 ## Quick answer A successful chart render or download click proves very little. First create a synthetic source dataset with known values. Then assert the business result at the strongest observable layer: displayed labels/totals, underlying API response, accessible table, downloaded filename, file schema, row count, and exact values. Keep manual or unsupported checks visible. ## Define the business oracle Use a fixture whose answer can be calculated independently: ``` Dataset version: sales-fixture-v3 Rows: 4 Expected categories: North, South Expected gross total: 1,250.00 USD Expected North total: 750.00 USD Expected export columns: region, orders, gross_usd Expected export rows: 2 data rows plus header ``` Do not derive the expected total from the same UI or export being tested. ## Evaluate chart assertions | Layer | What it can prove | Example assertion | | ------------------------- | --------------------------------------------------- | -------------------------------------------------- | | Visible UI | User can see the intended summary | Title, categories, units, total, selected filter | | Accessible representation | Semantics are exposed to assistive and test tooling | Labels and values have meaningful accessible names | | Table or tooltip | Individual values match fixture | North = 750.00 USD | | Network/API | Source payload is correct | Two categories and expected totals returned | | Image comparison | Rendering has not shifted materially | Reviewed visual baseline within policy | An API assertion alone does not prove the chart shows the right value. A screenshot alone may not prove numerical correctness. Combine layers according to the risk. ## Evaluate downloaded files Separate these gates: 1. the action triggers a download; 2. the download completes; 3. filename and extension are correct; 4. file is readable and matches the expected format; 5. schema, worksheet names, headers, and required columns are correct; 6. values, row counts, units, locale, and filters match the fixture; 7. sensitive or cross-tenant data is absent; 8. the test deletes or safely retains the artifact. Playwright’s current download API emits a download event and provides the URL, suggested filename, and payload handling, while noting that temporary downloads are deleted with their browser context. If a ContextQA workflow uses custom code or exported Playwright for content validation, verify the exact supported mechanism in your environment before documenting it as product behavior. ```mermaid flowchart LR A[User action] --> B[Chart or downloaded artifact] B --> C[Extract observable values] C --> D[Compare with business oracle] D --> E{Correct outcome?} E -- Yes --> F[Pass with evidence] E -- No or unknown --> G[Fail or escalate] ``` ## Create an honest capability matrix | Assertion | Automated and observed | Manual review | Unsupported / not evaluated | Evidence | | ---------------------------- | ---------------------- | ------------- | --------------------------- | -------- | | Chart title and filter | | | | | | Displayed category totals | | | | | | Canvas-only pixel details | | | | | | Download event and filename | | | | | | CSV schema and exact values | | | | | | Complex spreadsheet formulas | | | | | | PDF visual pagination | | | | | Do not convert “click worked” into “file content validated.” ## Run negative controls * change one chart source value and confirm the displayed-value assertion fails; * remove one required export column and confirm schema validation fails; * include a tenant-B row and confirm the boundary assertion fails; * apply a filter mismatch and confirm the row-count or total assertion fails; * return an empty or corrupt file and confirm the run does not pass. ## Frequently asked questions ### Is a successful click or download event a sufficient assertion? No. It proves only that the interaction occurred. The test must also verify the business outcome: the expected series or value for a chart, or the filename, format, schema, records, totals, and authorization boundary for an exported file. ### When is OCR acceptable for chart validation? Use OCR only when visible text is the intended user-facing oracle and its error rate is acceptable for the risk. Prefer accessible labels, underlying data, or a supported API when they provide a more stable and precise observation. ### What if the testing platform cannot parse the downloaded file? Keep the browser step responsible for producing and identifying the artifact, then pass it to a deterministic parser or downstream validation step. Report the workflow as partially automated rather than treating the unverified file as correct. ## Related documentation * [Playwright Downloads](https://playwright.dev/docs/downloads) * [Playwright Assertions](https://playwright.dev/docs/test-assertions) * [Validate API Responses](/api-testing/validating-responses.md) * [Custom Code Steps](/web-testing/custom-code-steps.md) {% hint style="info" %} [**Evaluate one representative chart or export →**](https://contextqa.com/book-a-demo/?utm_source=learning.contextqa.com\&utm_medium=referral\&utm_campaign=docs_demand_gen\&utm_content=chart_download_assertions). ContextQA support should be scoped to what is actually demonstrated. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://learning.contextqa.com/planning-and-decision-guides/chart-and-download-assertion-evaluation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.