Controlling renders to allow tests to inspect render tree before it changes

[egil]

Hi Blazor team

I am seeking more insight into the renderer.

Background:
In bUnit, test code (i.e. the actual [Fact] in xUnit parlor) runs in the synchronization context of the test framework, and the Blazor renderer runs with the default dispatcher, and thus its own synchronization context.

This can cause some race conditions between test code traversing the render tree (through GetCurrentRenderTreeFrames(componentId)) while the renderer is asynchronously in its own thread performing re-renders, which updates the render tree. This can happen if a component asynchronously directly or indirectly triggers one or more re-renders, e.g. by awaiting services, or timers (Task.Delay).

Goal:
I want to confirm my solution and understanding of the renderer before I try to improve and simplify bUnit's the code. The goal is to prevent renders while test code is traversing the render tree.

My understanding is that void ProcessPendingRender() is called before a any render, and UpdateDisplayAsync(in RenderBatch renderBatch) is called after a render. Another render is not started before the Task returned from UpdateDisplayAsync(..) is completed.

Is this correct?

Further discussion:
I am pretty sure there would fewer be problems related to this if bUnit was not doing a complete rebuild/replace of the DOM tree when a render occurs by calling GetCurrentRenderTreeFrames(componentId) for every updated component and sub component affected by a render, and instead just used the contents of RenderBatch passed to UpdateDisplayAsync to update an existing DOM tree, like Blazor does.

To do this would however require bUnit to reimplement the TypeScript DOM tree update logic in C# with AngleSharp as its target (which I guess is doable since AngleSharp matches the DOM api pretty closely). It's on the TODO list, but there might still be a need to control updates to the DOM tree from a test perspective though.

cc. @SteveSandersonMS, @danroth27, @captainsafia.

[SteveSandersonMS]

The safe way to read the rendertree is synchronously during the UpdateDisplayAsync call. I guess you're saying it's difficult for bUnit to do that, but I'm unsure what restriction makes it difficult.

Do you think you could maybe post a small code snippet that illustrates the interaction between bUnit framework code and the renderer, showing why the bUnit parts can't be triggered by the UpdateDisplayAsync call and read whatever information they need synchronously during that time?

Thanks!

[egil]

@SteveSandersonMS, that's actually how bUnit is doing it currently, but only for re-renders and not for initial renders. And it was the initial render scenario that is causing a subtle bug once in a while (bug 189) that prompted me to revisit this. The problem is that when a component has an await statement in the OnInitializedAsync life-cycle method that causes it to change the render tree when the awaited statement completes, it will sometimes cause a race condition.

So I am just seeking to confirm my options and understanding before I redesigned some of code in TestRenderer, to hopefully get this right this time 🤞😉.

Thus, is this correct?

• While UpdateDisplayAsync is blocked another render will not happen.
• Another render is not started while the Task returned from UpdateDisplayAsync is running/incomplete.

Thanks

[egil]

Follow up from me on this @SteveSandersonMS:

The TestRenderer exposes the method FindComponent<TComponent>(int parentComponentId), that the user can call from test code to find an already rendered component in the TestRenderer. The FindComponent works by looking at the current render tree of the parent component through the GetCurrentRenderTreeFrames method and then walks down that tree recursively calling GetCurrentRenderTreeFrames on sub components until it finds a component with a matching type of TComponent.

If a component in the parent component's tree, which is being visited by FindComponent, is asynchronously rendering at the same time as FindComponent is being invoked, unpredictable results can occur.

My solution is to wrap ProcessPendingRender in a lock that is also used by FindComponent. This should have the effect that when FindComponent is doing its work, a new render cannot start, and when rendering is being done FindComponent have to wait.

E.g.:

private readonly object _renderTreeAccessLock = new object();

// ...

protected override void ProcessPendingRender()
{
	lock (_renderTreeAccessLock)
	{
		base.ProcessPendingRender();
	}
}

public IRenderedComponent<TComponent> FindComponent<TComponent>(int parentComponentId)
{
	lock (_renderTreeAccessLock)
	{             
		// GetCurrentRenderTreeFrames getting called here for every component under 
		// parentComponentId until a matching component is found.
	}
}

Is this a sound approach?