IGP-Fan-Reference/docs/AI Gen Docs/test-network-resilience.md

type, status, category, isAgentGenerated

type	status	category	isAgentGenerated
Task	AI Gen TODO	QA	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.