Does bUnit handles Multi-threaded test execution?

[ScarletKuro]

Hi,
We’re planning to enable

[assembly: Parallelizable(ParallelScope.Fixtures)]

in our NUnit + bUnit tests to speed up execution. I’m wondering how well bUnit handles this, or whether it’s something that might bite us later.

I know bUnit has GetAwaiter().GetResult() guards in place, but in our case we actually bypass them here:
https://github.com/MudBlazor/MudBlazor/blob/dev/src/MudBlazor.UnitTests/Extensions/IRenderedComponentExtensions.cs

But, we don’t bypass them for cases like:

var bar = Context.Render<MudAppBar>();

Also, are there any plans to add a RenderAsync to avoid blocking?

[linkdotnet]

Hey @ScarletKuro.

Using FixtureLifeCycleAttribute.InstancePerTest if that is applicable for you, should make it faster and I don't see a problem then. Alternatively, you can create a new BunitContext per test-case, but that needs refactoring-effort.

bUnit does not have much state (the RenderTree might be the only important one). The underlying Blazor-Renderer also doesn't store state to my knowledge.

We are not relying on static parts, so from that perspective, it is safe to use.

Can I ask what exactly you want from:

Also, are there any plans to add a RenderAsync to avoid blocking?

I am asking because the Render call is a non-blocking eventhough it might doesn't seem so. If your OnInitializedAsync stuff has real async work (not a Task.CompletedTask), we are not awaiting that.

[ScarletKuro]

bUnit does not have much state (the RenderTree might be the only important one). The underlying Blazor-Renderer also doesn't store state to my knowledge.

Thanks, that’s very helpful information.

Can I ask what exactly you want from:

I remember there being some mentions of such an API in the past, and I assumed the reason was that Render was blocking. I wanted behavior closer to Blazor.

I am asking because the Render call is a non-blocking eventhough it might doesn't seem so. If your OnInitializedAsync stuff has real async work (not a Task.CompletedTask), we are not awaiting that.

didn’t know that, because I thought it was the opposite, and we do have some real async work in OnInitializedAsync / SetParametersAsync etc..

[linkdotnet]

I think we toyed with the idea of RenderAsync solely due to deadlock reasons.
But the underlying Blazor Renderer just batches stuff anyway - so even an awaited RenderAsync does not really await for example, OnInitializedAsync and SetParametersAsync.
Or put it differently: It wouldn't be like that out of the box without hooking in deeply into the renderer.
The gain is not that big given that we have WaitForXXX to circumnavigate that situation in the first place.

But if you have more questsions/Suggestions, always shoot!