[Blazor] Playwright e2e testing with InteractiveAuto

[mip1983]

In my Blazor App my components are written in a way that they can potentially run in 'InteractiveAuto' mode, i.e. be Server or wasm and talk to the back end via http clients.

While this works generally, I've found the reality to be that just because something is working on server, doesn't mean there aren't some quirks in behavior on wasm, particularly with some third party UI components that might for example, be doing a lot of JS interop. The kind of problem I might run into could be around async/await, where something will behave on server rendering, but in wasm mode, need a bit of a hacky 'await Task.Delay(5);' to kick along a bit of behavior not triggering (usually having spent too long trying variations of 'StateHasChanged()' here and there). I don't think I've found issue's in reverse, generally if it's working on wasm, it'll work on server.

Are there any recommendations on how to do automated e2e testing on Blazor with the likes of Playwright so that you know your auto components are working in both modes? And/or is there a way for a test run that you could tell the app to run all 'InteractiveAuto' components as wasm? I guess if you could do that, you could be reasonably confident(ish) that they'll behave in server mode.

In reality, I've stopped using 'InteractiveAuto' due to the above, I just run everything as 'InteractiveWebAssembly'.
I'd love to see real multi-threading on async/await with wasm, not particularly for performance reasons, but just to get more behavior parity between server and wasm.

[mr-baraiya]

When using InteractiveAuto, there isn’t currently a built-in way to force all components to run in WebAssembly mode during a test run.

A common approach is to run separate Playwright test runs against two configurations of the app:

1. Run the app in InteractiveServer mode and execute your e2e tests.
2. Run the app in InteractiveWebAssembly mode and execute the same tests again.

This ensures the UI behavior works in both rendering models.

For Playwright, you can start the app with different environment settings or launch profiles (for example different ASPNETCORE_ENVIRONMENT values) and run the same test suite against each deployment.

In practice this is the most reliable way to catch behavior differences between server and WASM when using InteractiveAuto.

[mip1983]

Ok, is there a way to force the app into server/wasm centrally?

[mr-baraiya]

Yes, you can control the render mode centrally by configuring it at the root of the application instead of relying on InteractiveAuto.

For example, in Program.cs you can explicitly choose the render mode when mapping Razor components:

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode();

or

app.MapRazorComponents<App>()
    .AddInteractiveWebAssemblyRenderMode();

For testing scenarios, a common approach is to toggle this configuration using environment variables or launch profiles. For example:

• Run the app with Server render mode for one Playwright test run.
• Run the app with WebAssembly render mode for another test run.

You can conditionally configure this in Program.cs:

if (builder.Configuration["RenderMode"] == "wasm")
{
    app.MapRazorComponents<App>()
        .AddInteractiveWebAssemblyRenderMode();
}
else
{
    app.MapRazorComponents<App>()
        .AddInteractiveServerRenderMode();
}

Then run your Playwright tests twice with different environment values (e.g., RenderMode=server and RenderMode=wasm). This lets you centrally control the render mode and verify behavior across both hosting models.