dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.32k stars 9.97k forks source link

Unable to write Integration Tests for Blazor Webassembly (deps.json is missing) #44909

Closed carlblanchard closed 1 year ago

carlblanchard commented 1 year ago

Is there an existing issue for this?

Describe the bug

.NET Core - 6 Blazor Webassembly (Standalone) Visual Studio 2022

When using WebApplicationFactory to launch a hosted WebAssembly application I receive a message saying that deps.json is missing from the bin path.

This is the same issue as https://github.com/dotnet/aspnetcore/issues/40549 which has already had a response. image

I would like to have https://github.com/dotnet/aspnetcore/issues/40549 reopened as I'm afraid I have to disagree with the response in which issue 40549 got closed for the following reasons. 1, WebApplicationFactory is for starting a hosted process as described on the Microsoft page in the following screenshot image 2, Playwright looks to be a great browser automation framework, however, it depends on an already hosted solution. The problem that the creator of 40549 and I are facing is that WebApplicationFactory does not seem to support Blazor Wasm.

Expected Behavior

To have the Blazor WASM website hosted in memory for the purpose of integration tests.

Steps To Reproduce

Create a Test project that references a Blazor WASM project.

Create WebApplicationFactory instance in a simple test and run the test under debug.

    public SimpleTest1()
    {
       var backendApplication = new WebApplicationFactory<Program>
           .WithWebHostBuilder(builder =>
           {
               builder.ConfigureServices(services =>
               {
                   //services.AddSingleton(SomeService);
               });
           });

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

javiercn commented 1 year ago

@carlblanchard Thanks for contacting us.

WebApplicationFactory is for starting a hosted process as described on the Microsoft page in the following screenshot

Unfortunately, this is not the case, WebApplicationFactory is for creating an in-memory server, not a separate process. The documentation that you are referring to is for server workloads not for things like Blazor Webassembly or other SPAs.

The problem that the creator of 40549 and I are facing is that WebApplicationFactory does not seem to support Blazor Wasm.

As mentioned above, WebApplicationFactory is meant for server scenarios, not UI testing. The recommendation we provided still applies in this case.

carlblanchard commented 1 year ago

If the environment set up is WebAPI > Blazor WASM front end and are all part of the same visual studio solution. Why wouldn't you want to start the WebAPI and Blazor WASM using webApplicationFactory and make it really easy for testers to create end-to-end tests in Memory? I'd be very interested to know how you purpose to host the Blazor WASM app because even If I go to the files in wwwroot it fails to work unless it's being served by a server.

What would you propose should launch and host the Blazor Application if the WebAPI is being hosted in the WebApplicationFactory ?

Also I've raised the same question in playwright because the documentation for the advanced stuff like creating a host process is not defined https://github.com/microsoft/playwright-dotnet/issues/2369

javiercn commented 1 year ago

There are two ways of doing this:

What would you propose should launch and host the Blazor Application if the WebAPI is being hosted in the WebApplicationFactory?

It is unclear to me what type of test you are trying to write, could you provide a concrete example?

Maybe if you look at some of the E2E tests within the Components folder in this repo, might shed some light into the approaches we use for validating blazor.

carlblanchard commented 1 year ago

Hi @javiercn thanks for the confirmation, I already use the dotnet run approach with Specflow, Selenium etc. These are the kind of scenarios that are being implemented. image The problem I've always found is testing using such technologies is slow and cumbersome.

When I discovered webApplicationFactory I was thinking, it would be so great to be able to spin up the WebAPI > Front end and run them all in memory, I could mock the database, storage, and all sorts of dependencies, thanks to the service injection webApplicationFactory provides. This would speed up the testing phase dramatically which would be awesome. Not only that, as they're running in memory, which makes setting up and tearing down a thing of the past.

It would be amazing to get some fast end-to-end testing going that doesn't take ages to run right on the developer's desktop before even raising a PR. I really think this is what the person of https://github.com/dotnet/aspnetcore/issues/40549 was trying to also achieve.

The webApplicationFactory possibly could be the perfect candidate to have a unified way of spinning up any web application, whether it be server-side or client. Directly within VS to perform end-to-end testing which would offer developers & dev testers a really simple way to get good, end-to-end testing going on locally before the CI-CD process.

It would certainly be a win win.

javiercn commented 1 year ago

@carlblanchard the problem is that you need a browser to test all those things. You would need a browser-like environment that you can connect to the instance of the API running in memory. As for mocking services, etc. You still can likely do so even if you run the real app. It requires a different approach, like maybe using a hosting startup assembly to change the service registrations while they are happening.

We do not plan to invest in an alternative approach to do UI testing because we believe that the current options are superior to whatever we can come up with. If you want to test webassembly apps, the best way to do it is inside a browser. Otherwise, you are effectively creating your own browser which is likely to resource intensive and is not going to match reality well.

carlblanchard commented 1 year ago

No, you're misunderstanding the browser is provided by playwright or selenium what's missing from this picture is the ability to host the front end nicely.

javiercn commented 1 year ago

No, you're misunderstanding the browser is provided by playwright or selenium what's missing from this picture is the ability to host the front end nicely.

From what I understand, you need two things:

For the server it can be (assuming WebApplicationFactory):

Adding Static web assets manually is probably needed too if you are not running the published app (in both cases).

All webapplicationfactory gives you is an HTTP Client instance you can use to talk to the server, so you need a way to connect the browser to that. It is theoretically possible with Playwright, but again, this is not something we plan to support now or in the near future and not something we currently recommend.

Unless there is an actual issue with a clear root cause that affects the server project used to serve the files, we can't take action here as we do think that WebApplicationFactory works well for the scenarios it was designed for.

carlblanchard commented 1 year ago

Okay thanks for your time.