Knowing all OnInitializedAsync() have completed and IRenderedComponent.Render()

[DavidThielen]

Hi all;

I think the first part of this question may be answered by the second part, but I'm asking each in case I don't fully understand all this.

1. How do I await until OnInitAsync() has completed for my page, including for every child component in it? In my particular use case I have pages where the page itself has no OnInitializedAsync() call but has several components that each have a OnInitializedAsync() that is hitting the database. If I go to test immediately, I get the "Is Loading" text on the page. I want to assert the page after it is fully populated. The solutions I see are:

   1. Have a MyPage.IsLoaded property and then call rc.WaitForState(() => rC.Instance.IsLoaded).

   2. Have the call rc.WaitForState(() => rc.FindAll(" ... ").Count > 0), once for each inner component, finding the html node at the end of the rendering in each of the inner components.

I'm not wild on solution 1.i as that requires the inner components talk to the parent telling it when they're all rendered. And 1.ii is messy, but it should work.

Why would I call IRenderedComponent.Render() to re-render the page? Is it:

1. To solve the above problem 1? So it then renders the page twice, but I now know it is fully rendered?
2. Is it to be the equivalent of calling StateHasChanged() in the page code? So I can set some parameters and then I need it to re-render for those new values?

thanks - dave

[linkdotnet]

Hey,

How do I await until OnInitAsync() has completed for my page ...

In v1, that isn't that straightforward, but it is on our radar and we have plans for v2 to tackle that. Nevertheless, for the time being, you might come around the issue via mocking/faking your database calls with something that ends up with a "finished task" rather than something asynchronous (like a real DB call). Basically taking out the side-effect part of your test and make it predictable/deterministic in behavior.

Why would I call IRenderedComponent.Render() to re-render the page?

You would call this method if you change/setup something in your test that should be reflected in your Blazor code. For example, you change the authorization in your test and want to reflect those changes to your production code. Or you change a two-way bound variable or cascading parameter that you defined in your testcode.

[DavidThielen]

Hi;

Thanks for answering. And on the "everything has rendered" issue - you're having to make up for a shortcoming in Blazor so that's on them, not you.

• dave
  ps - I think bUnit is very well designed. Thanks for an incredibly useful and easy to use library.

[egil]

You have to frame the problem slightly different, I think.

The reason why you want to wait for all OnInitAsync to complete is because you are aware of how your components work internally. However, your tests should not rely on implementation details, if at all possible. If they don't, you are able to refactor your components without breaking your tests.

Instead, when you create tests, focus on the externally observable behavior of your components, i.e. look at them from the end users point of view. So, if you are waiting for your components to render, then that probably means there are certain things available in the DOM (cut.Nodes or cut.Markup) that indicates this.

So instead of waiting for internal state, e.g. cut.Instance.IsLoaded, wait for one or more elements to appear in the DOM, e.g. cut.WaitForElements(''..."). If you change implementation details later but the elements are still there, then the tests still pass.

[DavidThielen]

My concern with using elements is the UX people keep moving/changing them. So depending on an element leads to unit tests breaking when they make those changes. That's why I like using the property - I control that.

[egil]

Yeah, that is the problem with UI testing. One approach is to lean into the philosophy outlined here https://testing-library.com/docs/guiding-principles, and we actually have a contributor working on role-based query API for bUnit that will make that even easier, but it can also be done today with some creative CSS selectors passed to Find and FindAll.

[DavidThielen]

The submit button at the bottom tends to not change. What are your thoughts on waiting for finding <input id="use-me" ... />? It's generally at the very bottom/end of the page and we have to have that for the page to work.

And if this is good, is WaitForElement() better than WaitForAssertion()? I dislike causing exceptions in the happy path.

??? - thanks - dave

[egil]

I don't know your scenarios for sure, but it sounds like a good idea.