What problem does it solve?
Aspire Dashboard UI and logic are tested in two different ways (non-Blazor model logic vs Blazor component rendering), and teams need consistent patterns to avoid brittle tests and repeated DI/JS-mock setup.
Core Features & Use Cases
- Choose the right test project: Use Aspire.Dashboard.Tests for non-Blazor code and Aspire.Dashboard.Components.Tests for Blazor pages/components using bUnit.
- Use correct test patterns and conventions: Apply xUnit patterns for non-Blazor tests and extend the required bUnit base class for component tests.
- Reuse shared DI setup and JS interop mocks: Centralize dashboard service registration and FluentUI JS interop stubbing via the provided shared setup helpers.
- Simulate real-time updates deterministically: Use channels and WaitForAssertion to validate async UI/state transitions.
Quick Start
Tell the AI: "Create a new bUnit test for the Aspire Dashboard Metrics page that uses the shared setup helper, mocks required FluentUI interop, and verifies the rendered output after pushing an update through the test dashboard client."