Closed eduralph closed 2 years ago
Rick-Anderson
commented
2 years ago I think I'll move this to https://github.com/dotnet/AspNetCore.Docs/issues/16341 and name it "Update for .NET 6". @guardrex to comment on Blazor comments. See all open issues on this topic
guardrex
commented
2 years ago @eduralph ... I don't understand your remarks about this article ever applying specifically to Blazor or Razor components.
There are no plans to carry integration testing coverage for Blazor in this topic. We maintain unit testing and E2E testing coverage for Razor components in a dedicated Blazor topic ...
https://docs.microsoft.com/aspnet/core/blazor/test
... and the article, written by Egil Hansen (creator of bUnit), mentions and cross-links Playwright. We rely upon their documentation at that point and not carry anything for their testing framework in the Blazor docs.
eduralph
commented
2 years ago @guardrex, you are right - I mixed up some stuff primarily of the nature of integration tests. I'm happy to slice it down a bit to get it to the right folks and apologies for the lack of clarity.
Anyways, I think the page is suffering more from need of context and the specific solution then actual errors. The "Web Apps" section is at the same hierarchy level as the "Test, debug, and troubleshoot" section. In the Web Apps section you have the different application types such as MVC, Razor, Blazor & Client-side. In the "Test" section you have a chapter called "Integration testing" but it covers only MVC & Razor not Blazor or Client-side Integration testing. I get the choice, but I think this needs to be communicated better.
The Blazor part covers components tests only, not integration tests. It's easy to assume that the "Integration tests" section covers all technologies which it unfortunately doesn't. If you have Blazor pages and want to do integration tests, using a WebApplicationFactory as host of the SUT as described in the "regular" part will fail. The Blazor dev team has addressed this issue in their own code already and some bloggers have picked up on it - albeit with errors unfortunately.
Finally, I think there is an error in the coverlet part of integration testing for Blazor - it appears that coverlet doesn't handle the shared layout pages correctly. It counts the "@Body" tag as code but doesn't recognize that the layout page has been integrated properly. At least I can't get the test engine to recognize it's being rendered.
guardrex
commented
2 years ago I see ... you're using language to describe the doc set that we don't use or use differently. Your "section" is our "node" or "folder" of topics, for example. When you say "page," you're lumping in the ToC (table of contents) in the sidebar, but that's a separate repo file (toc.yml)/UI area for us. To us, the "page" is just the article's content. We discuss the sidebar and navigation as a separate issue to whatever article has loaded. Anyway ... yes ... I understand what you're addressing now.
We're not going to ever place the Blazor test topic in this node. A decision was made by management a long time ago to keep all of the Blazor content together under one ToC node (under Web apps), so the best we can do elsewhere in the ASP.NET Core main doc set is cross-link to Blazor articles where needed.
@Rick-Anderson, I think the Integration testing topic will need a cross-link to get readers over to the dedicated testing topic in the Blazor node. It could be in Additional resources, but that might be too deep and too late or just not noticed to get readers to the right spot. Perhaps, an early (very short) section or even just a single sentence in the opening remarks will make readers aware of the Blazor-specific topic ... or perhaps a NOTE at the end of the opening remarks before the first H2.
coverlet part of integration testing for Blazor
But there is no integration testing coverage for Blazor (we link out to Playwright), and I don't know what "coverlet part" means.
"@Body" doesn't appear in either article. If you're referring to use of Playwright with Blazor ... and that's where this @Body issue is cropping up ... it's best if Playwrite docs cover it. I think you would need to open an issue with them if you'd like to see detailed coverage on how to handle it. For the Blazor topic, we could have a NOTE on it and cross-link to their coverage on how to include the layouts for integration testing. Whatever the case, that would be a separate issue for that topic, so you'd need to use the This page feedback button and form from that topic. We usually work Blazor issues for Blazor topics separately from the main ASP.NET Core doc set.
You can leave this issue open, as I think Rick will want to cross-link somehow to the Blazor topic. This issue will close automatically when his (or Wade's) PR merges later.
eduralph
commented
2 years ago In case of the documentation of Blazor, given the constraints, I would suggest creating an integration test content for Blazor and just add a reference at the bottom. The page might get too top-heavy with "consider this & that" unless you get that feedback more often... if you need any help on that, let me know.
As to the coverlet thing - go ahead and ignore, I'll drop a note directly to the maintainers there.
Thanks!
Rick-Anderson
commented
2 years ago @Rick-Anderson, I think the Integration testing topic will need a cross-link to get readers over to the dedicated testing topic in the Blazor node. It could be in Additional resources, but that might be too deep and too late or just not noticed to get readers to the right spot. Perhaps, an early (very short) section or even just a single sentence in the opening remarks will make readers aware of the Blazor-specific topic ... or perhaps a NOTE at the end of the opening remarks before the first H2.
an early (very short) section
An early section pointing off would be good and add the link to the additional resources.
The article appears incompletely re-worked over the original setup a year ago. It originally used Anglesharp to parse results from Blazor. It now speaks of using Playwright in the beginning but then continues with Anglesharp after chapter Test app prerequisites
Also, the inheritance from a WebApplicationFactory for Blazor does not work anymore, instead one needs to use a generic aspnet core host for hosting the Blazor components, otherwise the loading will fail.
If one seperates the setup in Frontend - Blazor, Backend - WebAPI setup, an end-to-end solution requires loading the different solutions in different threads to listen on different ports. One might not want to overcomplicate the article with that, there are still some extra steps to go. The aspnetcore team has an example how to do this.
Finally, the article unfortunately doesn't talk about coverage. At this point I suspect that there are some holes in calculating coverage in Blazor (which I will explore) as well as issues when loading in separate threads.
Ping me if you would like to discuss the items - I'm happy to share the code I have.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.