Hi ,

My view is that the testing approach should focus on validating the underlying data and query logic, rather than the rendered visual itself.

AI/BI Dashboards are built from datasets, visualisations, and filters. In other words, the chart or table a user sees is a presentation of a dataset after aggregations, filtering, and formatting have been applied. If the goal is data quality validation, the most stable thing to test is the data contract behind the dashboard which includes source tables, views, metric definitions, dataset SQL, and expected filter behaviour.

That is usually a better fit than testing "what the widget rendered" for a few reasons:

• Visuals are not the source of truth. The source of truth is the underlying dataset and business logic.
• Dashboards can apply visualisation-specific filtering and aggregation differently depending on dataset size and execution path.
• Rendering itself has limits and optimisations, so validating the visual can end up mixing data correctness with presentation/runtime behaviour.

Databricks documents this behaviour explicitly. For smaller datasets, the dataset result can be pulled to the client, and visualisation-specific filtering and aggregation are performed in the browser. For larger datasets, visualisation-specific filtering and aggregation are performed on the backend instead. That means there is not always a single simple "widget result" object exposed as a stable public API contract that exactly represents what was rendered.

So in practice, I would recommend:

1. Validate the source tables/views or metric views.
2. Validate the dashboard dataset SQL.
3. Validate expected filter semantics and aggregations.
4. Use dashboard-level checks only as smoke tests to confirm the dashboard is wired correctly.

That last point matters. There is still value in lightweight dashboard tests, for example:

• confirming the right filters affect the right widgets
• confirming expected aggregations are shown
• confirming cross-filtering or drill-through behaves as expected

But I would treat those as product behaviour checks, not as the primary layer for data quality testing.

So the short version is.. validating the underlying data is the better and more reliable approach than validating the visuals themselves. The visuals are important for user experience, but the data layer is the right place to anchor automated correctness tests.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

Thanks for u detailed answer on the dashboard validation testing.