Why isn't there a WaitForSettledDown()?

[DavidThielen]

Hi all;

I'm sure this has been asked before, but I couldn't find it. Why isn't there a call to WaitFor everything to render, all async calls to complete, etc.?

I'm asking in the context of #1276 where I need to set the value in an <input> component and need to wait for that to be set and the IsValid() to be executed. In this case, there is no component appearing or disappearing. All that changes is the content of that component. And the solution for my issue here may be that instead of setting up a page, and then testing 4 different bad emails, one after the other, instead I need 4 tests where each starts with an empty <input>, gets the one bad value, asserts that, then done.

But back to the general question - why isn't there a WaitForEverything() call? Even if it can't handle my SetText()/IsValid() case, it can at least wait until all OnInitializedAsync() & OnAfterRenderAsync() calls have completed? Or maybe a WaitForAllTasks() that will wait until all tasks running at the time it is called complete?

And you all are clearly smart and know your stuff. So there's probably a good reason this can't be done. But if so, could you explain why? Because that will help me understand what I'm working against as I write my tests and use WaitFor

thanks - dave

[egil]

Consider this scenario. You have a component with a Task.Delay(1 second) in an OnInitialized. We cannot know that. We do know when the renderer is idle, but that may change at any moment based on the components under test.

We simply don't know.

Now, if you have a component state you want to wait for to happen, but it's not externally observable from either the markup or object state, or dependency state, you may be trying to write a test that is verifying implementation details about your component, which is not recommend. Tests should never be tied to or assert on implementation details.

[DavidThielen]

First off, thanks for answering.

In the Task.Delay() scenario, can't you track if OnInitializedAsync() has completed? Or do you not have visibility of the Task it returns?

As to your comment about not depending on "implementation details", aren't we always doing that? For example, enter an invaild email, I expect to see an error message. It's an implementation detail that the error message is in a renderedComponent.Find("li.validation-message"). Or am I misunderstanding your meaning of "implementation details"?

I'm trying very hard to understand what I should do and not do right now. I'm learning bUnit and what I do over the next 2 weeks will look in how I write bUnit tests for years. So I want to get it right.

thanks - dave

[linkdotnet]

There are two levels of implementation details.

First: ComponentBase which you normally use - is, in fact, an implementation detail. The Blazor renderer only enforces IComponent. So ComponentBase provides all the Life-Cycle events and not Blazor (Renderer) itself.
But you can create Blazor components that "only" derive from IComponent and could implement their own lifecycle.

Second: That brings us to your example of validation messages - and they are in fact not an implementation detail: Because they are directly facing your user. That there is a model, EditContext and maybe some custom ValidationAttributes involved - that is an implementation detail.
Of course, you need some meaningful way to look for that error message (which tries to be stable and as little dependent on external factors as possible) - so, as always, it is compromise between exposing details and convenience.

[DavidThielen]

I think the "correct" way would be for <ValidationSummary/> to put an id= or name= on whatever element has the error message. And promise that that id/name will never change.

However, that's not in my control.

[linkdotnet]

The short answer to your question is that we might introduce that in the future. The Blazor team itself has functions like WaitForQuiescenceAsync on the, now public, HtmlRenderer.

To put it simply: It isn't always easy to find out, that stuff is going on or better that stuff will go on.
For example: You can have timers that constantly trigger re-renders of the UI. From the renderers point of view that is impossible to tell.

Personally in my tests I try to fake out all asynchronous stuff as much as possible. An external call can be mocked most of the times (for example if you put it into a separate service) and the mocked service can use something like Task.FromResult.

[DavidThielen]

What do you mean by "fake out all asynchronous stuff"?

My code is as async as possible, not just that it has OnInitializedAsync() instead of OnInitialized() but that inside that the code is as async as possible including kicking off multiple tasks when possible and then doing a Task.WhenAll() before completing.

I do then have mock services that run synchronously when called. So everything should in fact run synchronously when called by bUnit. Is that what you mean?

And in this case, aren't the Tasks still set up, but then just immediately wound down as completed? Does this mean it can still be waiting for these completed tasks to unwind? And I'm droning on...

Anyways, any guidance is appreciated.

thanks - dave

[linkdotnet]

I do then have mock services that run synchronously when called. So everything should in fact run synchronously when called by bUnit. Is that what you mean?

Yes. And yes Tasks are still there, but they are directly completed from the get-go - therefore the Blazor renderer does everything synchronously. As you mentioned in the other thread - that would be an implementation detail.

[DavidThielen]

thank you for the help.