V2

[egil]

This is the parent issue used to track all the changes we want to include in bUnit v2:

• Enable documentation for v1 and v2 #1205
• Docs: Create migration guide
• Consider removing TestContext.RenderTree. Users can easily do this themselves. Investigate the usage of this feature.
• Rename TestServiceProvider to BunitServiceProvider
• Remove unneccessary abstraction #1015
  • Use a single RenderedComponent type. Render(renderfragment) would return RenderedComponent<BunitRootComponent>.
    • RenderedComponent should inherit from ComponentState
    • Enable walking component tree #1180
    • Make renderer, context, services directly available on type
  • Leverage new .NET 8 abilities in Renderer to simplify code
• Rename TestContext to BunitContext #963
• Remove all GetAwaiter().GetResult()
  • Make WaitForX methods async
• Remove all RenderComponent methods and replace them with additional overloads of Render method #1017
• Drop support for old frameworks
• Shared BunitContext, one BunitRenderer per Render() call #1018
• Rename TestRenderer to BunitRenderer #1019
• Mark and remove "Snapshot" based assertion #974

[linkdotnet]

Regarding "Refactor out unneeded abstractions (TBD)" - It would make sense to create a ticket which unifies IRenderFragmentBase,IRenderFragment, ... and friends to one exposing type.

[linkdotnet]

"Remove all GetAwaiter().GetResult()"

We have two options here to evaluate whether or not that helps us:

• Really, just use async/await everywhere.
• Or what you already started: Reimplement the renderer from "scratch". It could still lead to issues with async/await because of other reasons.

[linkdotnet]

We might wanna track all breaking changes as well as a small guide how to migrate from v1 to v2

[egil]

We might wanna track all breaking changes as well as a small guide how to migrate from v1 to v2

For this, we probably need it as a requirement to merge any PR for v2 that there is an updated section in the change log about the breaking changes, and perhaps also a docs page that has the same content.

[egil]

"Remove all GetAwaiter().GetResult()"

We have two options here to evaluate whether or not that helps us:

• Really, just use async/await everywhere.
• Or what you already started: Reimplement the renderer from "scratch". It could still lead to issues with async/await because of other reasons.

Some of the design choices in the current renderer is based on the fact that we are using mixing async and sync code, but by and large I do not think a complete rewrite is necessary.

That said, this would cause many side effects too, like the BunitContext.Render methods becoming async.

[egil]

I'm considering having V2 target .NET 8 only. The list of changes coming to Blazor in that release is significant, see dotnet/aspnetcore#44984.

[linkdotnet]

Quite some interesting features - let's see what makes the cut.

[linkdotnet]

Maybe another input / proposal from my side:
Currently, we have quite some topics for v2, including some that are currently not listed:

• Remove GetDiffSinceLastRender and friends
• Make elements update between rendered via AngleSharp factories
• PoC - find an abstraction so that the user can mock certain things
• Only support .NET 8

And there are items I missed ... so all in all kind of a big bang. Version 1 is almost 3 years old and ready to go to kindergarten ;)
The good thing is that with that fact, we have a stable API - but in the future, we could also try to go "fast" in the sense of we have v2 with only a few core features we deem the most important and after another year (or 1.5, you get the idea) we go to v3.

I do think your initial thoughts are a valid package for v2 as is. Depending on what @SteveSandersonMS is cooking, there will be more work to come for .NET 8.

[egil]

Thanks, Steven. I prototyped on the AngleSharp factories one, and it turns out it won't work. The hooks available in AngleSharp to control the nodes being created are incomplete, so that approach is unfortunately out of the picture.

The "mock certain things" refers to an abstraction around mocking/faking JSInterop, right? To be honest, considering the time limit we have, that may not make it.

I won't rule out keeping .NET6/.NET7 support around for now, unless there are too many #if in our code.

[linkdotnet]

With the latest preview 3 of ASP.NET Core, the HtmlRenderer is now publicly available. In the announcement, a simple snippet invokes the renderer in a console application.

For v2 we could evaluate if the HtmlRenderer could be somewhat integrated in bUnit. Unfortunately, a lot of things we need are not available and the class is sealed. So at first glance, it doesn't look viable.

[egil]

For v2 we could evaluate if the HtmlRenderer could be somewhat integrated in bUnit. Unfortunately, a lot of things we need are not available and the class is sealed. So at first glance, it doesn't look viable.

Yeah it's not meant for us.

[egil]

Lets track this using the milestone feature instead.