Can IRenderedFragment.WaitForElement() be used similarly to WaitForAssertion()?

[derek-baker]

The docs state:
"A test can fail if a component performs asynchronous renders. This may be due to a reason such as waiting for an asynchronous operation to complete before continuing its render life-cycle. For example, if a component is waiting for an async web service to return data to it in the OnInitializedAsync() life-cycle method before rendering it to the render tree.
[...]
bUnit comes with two methods that help to deal with this issue: the WaitForState() method covered on this page, and the WaitForAssertion() method".

Can IRenderedFragment.WaitForElement() be used to address similar issues?

I'm asking because I'm troubleshooting some tests that succeed very reliably when run locally on Windows, but fail more than 50% of the time when run by AzureDevops on an Ubuntu-based agent (.NET 6). Despite using WaitForElement(), the tests in question still pass or fail nondeterministically on the build server.

UPDATE: The tests still fail even after replacing WaitForElement() with one of the other methods.

I'm wondering if this issue could be related? #577

[linkdotnet]

Hey @derek-baker

WaitForElement("css-selector"); simplified is a WaitForAssertion(() => cut.Find("css-selector")); under the hood. So it makes sense that you test is flaky in both cases equally.

Can you post a snippet of the component and test which is flaky?

[egil]

Almost correct. WaitForElement is a shorthand for:

cut.WaitForState(() => cut.FindAll(selector).Count == 1);
var elm = cut.Find(selector);

which can be written as:

var elm = cut.WaitForElement(selector);

I know there should be documentation of the WaitForElement and WaitForElements, but I have not gotten around to it yet.

[derek-baker]

The flakiness I allude to above appears to be attributable to the structure of my tests, and not bUnit. Thanks!