Testing component with OnInitializedAsync

[SeanFeldman]

I'm following the documentation guidance on how to test with OnInitializedAsync loading data asynchronously.

The component is loading data for a select element in OnInitializedAsync, rendering all the controls once the data is loaded.

  protected override async Task OnInitializedAsync()
  {
      editContext = new EditContext(command);
      editContext.OnFieldChanged += EditContextOnFieldChanged;

      coordinatorsList = await IdentityService.GetCoordinators();

      dataLoaded = true;
  }

And on the razor page, inputs are only rendered when dataLoaded is true:

@if (dataLoaded)
{
  // form with inputs
}

To validate the happy path, I'm populating all the inputs and ensuring to wait for the state change in the following way:

cut.WaitForState(() => cut.FindAll("input").Count >= 9, TimeSpan.FromSeconds(10));

and right after that, updating all the form fields and submitting the form

cut.Find("#firstName").Change("Joe");
cut.Find("#lastName").Change("Doe");
cut.Find("#email").Change("[email protected]");
cut.Find("#coordinatorId").Change("1234567890");
cut.Find("#cellNumber").Change("123-456-7890");
cut.Find("#phoneNumber").Change("321-654-9870");
cut.Find("#postalCode").Change("12345");
cut.Find("#isContractor").Change(true);
cut.Find("#contractingRate").Change(75);
await cut.Find("form").SubmitAsync();

But WaitForState() fails with

Bunit.Extensions.WaitForHelpers.WaitForFailedException : The state predicate did not pass before the timeout period passed.

I've tried

cut.WaitForState(() => cut.FindAll("input[type='submit']").Count > 0, TimeSpan.FromSeconds(10));

But then I get random input that is not found, like "No elements were found that matches the selector '#firstName'"

I feel like I'm doing something wrong if WaitForState() doesn't work. When the number of the input elements is reduced, it works.

bUnit 1.4.15
.NET 6

[egil]

Hi Sean,

Its hard to know without seeing the complete test and component under test. A few notes though:

First of, you generally dont need to specify a long timeout. It is only needed if you have async code that you know for a fact might run long, e.g. a real database/web service call that takes more than one second. If you are controlling the async operations during testing, e.g. by mocking the data such that it returns immediately, then it should take less then a millisecond on a regular computer, and you do not have to extend the default timeout.

The different WaitFor... methods will actually only wait as long as they need for the condition to be met or assertion to pass, and the condition or assertion is checked after each re-render of the component under test or any of its child components.

Second, it is pretty uncommon to need to use the async version of the event trigger methods (e.g. await cut.Find("form").SubmitAsync();). In almost all cases, you want to just return, since Blazor will try to run all code synchronously if it can.

Where you problably need to look is in the event handler on the <form> element and see what that does.

[SeanFeldman]

First of, you generally dont need to specify a long timeout. It is only needed if you have async code that you know for a fact might run long, e.g. a real database/web service call that takes more than one second. If you are controlling the async operations during testing, e.g. by mocking the data such that it returns immediately, then it should take less then a millisecond on a regular computer, and you do not have to extend the default timeout.

That's exactly what I'm doing. I'm mocking the dependency (one or more) that would otherwise make HTTP calls, and return the data. And yet, still, I'm running into this issue that I have to wait for the state using WaitForState which occasionally just fails because it times out and the element is still not rendered. That's why I'm really wondering if what I'm doing is the right thing to do. The documentation (and your elaborate answer) make it sound that it's all that's needed while I'm getting this weird problem.

I'll play more with bUnit and hopefully will find my problem. Thank you, @egil.