Files
IGP-Fan-Reference/docs/AI Gen Docs/test-network-resilience.md
T
2026-05-31 14:33:58 -04:00

42 lines
1.8 KiB
Markdown

---
type: Task
status: AI Gen TODO
category: QA
isAgentGenerated: "true"
---
# Test: Network Resilience and WASM Loading
## Description
Verify the Blazor WASM app handles network failures gracefully — showing loading states, error boundaries, and retry behavior when `dotnet.js`, `.wasm` files, or `.dll` resources fail to load.
## Rationale
The app is a Blazor WASM single-page application that downloads the .NET runtime (`dotnet.js`, `dotnet.wasm`) and assemblies on first load. If any of these requests fail (server down, CDN outage, flaky connection), the entire app breaks. No existing test covers this failure mode; they all assume the dev or production server is reachable.
## Playwright Feature
This test uses **`page.route()`** (route interception) to selectively block or delay specific resource types:
| Test Case | Interception |
|---|---|
| `dotnet.js` fails to load | `page.route('**/dotnet.js', route => route.abort())` |
| `.dll` assembly fails | `page.route('**_framework_**', route => route.abort())` |
| Slow network | `page.route('**', route => route.continue({ delay: 5000 }))` |
| Timeout during WASM init | Combine slow network with reduced navigation timeout |
### What to Assert
- An error boundary element (`.blazor-error-boundary`, `#blazor-error-ui`) becomes visible.
- A user-facing message like "An unhandled error has occurred" or "Retry" appears.
- The `window.dotnet` global is undefined (runtime never loaded).
- The page body is **not** a blank white screen (user sees a styled error, not a crash).
- Clicking a "Retry" button triggers a page reload.
### Variations
- Block only `dotnet.wasm` but allow `dotnet.js` (tests partial-load scenario).
- Block `.pdb` symbol files (tests debug vs. release build quality).
- Simulate offline mode with `context.setOffline(true)` for full app navigation testing.