Why are the async methods private?

[LordBenjamin]

I have a test which calls component.Find("form").Submit() where subsequent assertions fail intermittently. This appears to be due to a race condition.

There is a private SubmitAsync() extension method (which Submit() calls internally, but discards the resulting Task without waiting).

Using await component.Find("form").TriggerEventAsync("onsubmit", EventArgs.Empty); fixes my test and is reliable. This is almost exactly how SubmitAsync() is implemented internally.

Could the async extension methods be made public? Or is there a good reason to keep these private, in which case should I use a different approach in my tests?

[egil]

Hi @LordBenjamin

The short explanation is that it is fairly easy to get into a deadlock like situation, where, if you have a component that does async stuff you are awaiting, but that async stuff is triggered by you providing data to a mock from the test or triggering an event handler from the test, then you cannot proceed.

The alternative pattern is described here: https://bunit.dev/docs/verification/async-assertion.html. Besides WaitForAssertion, there is also a WaitForState and in the preview release of bUnit, a WaitForElement and WaitForElements.

That said, you might have a corner case that I have not thought of, so I would love to get a small sample project which shows your scenario that I can investigate.

[LordBenjamin]

Thanks @egil - I think in some cases we could switch to WaitForState(), but sometimes we want to check that something doesn't happen, for example:

• Set up the form in an invalid state
• Trigger the submit
• Assert that our wasSaveMethodCalled bool is still false (because we're using OnValidSubmit, so we expect validation to fail and therefore our handling code should not be called)

e.g.

[Test]
public async Task TestSaveInvalid() {
    var component = context.RenderComponent<MyPage>();

    var fullNameField = component.Find("#fullname");
    fullNameField.Input("test");

    var emailAddressField = component.Find("#emailaddress");
    emailAddressField.Input(string.Empty); // Required field, empty string is invalid

    // was component.Find("form").Submit()
    await component.Find("form").TriggerEventAsync("onsubmit", EventArgs.Empty);

    Assert.IsFalse(mockApi.SaveUserCalled); // Expect not to be called as validation will fail
}

I can't think of a way to do this using WaitForAssertion / WaitForState as we expect the state not to change. On the other hand, await form.SubmitAsync() would allow us to confirm that the form submit ran to completion and we can then inspect the state to assert that it is as expected.

Given that SubmitAsync() is shorthand for TriggerEventAsync("onsubmit", EventArgs.Empty) which is a public method, we can still do this without changes to bUnit (if you think the risk of deadlocks is too high to expose this as a general-purpose method). In our particular test cases, we've not experienced deadlocks (in over 600 runs of the test), but I do appreciate that bUnit needs to be designed for the general case.

I must admit I just intuitively expected void Submit() to be a synchronous operation and so the test code reads sensibly at first pass (without checking whether the form submit handler is actually an async method or not).

I will see if I can get some time to put together a sample project rather than the slightly vague example above.

[egil]

Thanks @egil - I think in some cases we could switch to WaitForState(), but sometimes we want to check that something doesn't happen, for example:

• Set up the form in an invalid state
• Trigger the submit
• Assert that our wasSaveMethodCalled bool is still false (because we're using OnValidSubmit, so we expect validation to fail and therefore our handling code should not be called)

e.g.

[Test]
public async Task TestSaveInvalid() {
    var component = context.RenderComponent<MyPage>();

    var fullNameField = component.Find("#fullname");
    fullNameField.Input("test");

    var emailAddressField = component.Find("#emailaddress");
    emailAddressField.Input(string.Empty); // Required field, empty string is invalid

    // was component.Find("form").Submit()
    await component.Find("form").TriggerEventAsync("onsubmit", EventArgs.Empty);

    Assert.IsFalse(mockApi.SaveUserCalled); // Expect not to be called as validation will fail
}

OK. This is actually a use case where a SubmitAsync makes sense. My reason for making them private was to help users avoid pitfalls like I mentioned before. I will make the methods public again in the next release.

I can't think of a way to do this using WaitForAssertion / WaitForState as we expect the state not to change. On the other hand, await form.SubmitAsync() would allow us to confirm that the form submit ran to completion and we can then inspect the state to assert that it is as expected.

Yeah, it makes sense that you cannot wait for something that should not happen.

Given that SubmitAsync() is shorthand for TriggerEventAsync("onsubmit", EventArgs.Empty) which is a public method, we can still do this without changes to bUnit (if you think the risk of deadlocks is too high to expose this as a general-purpose method). In our particular test cases, we've not experienced deadlocks (in over 600 runs of the test), but I do appreciate that bUnit needs to be designed for the general case.

The general TriggerEventAsync will remain public, so its safe to keep using that.

I must admit I just intuitively expected void Submit() to be a synchronous operation and so the test code reads sensibly at first pass (without checking whether the form submit handler is actually an async method or not).

In general, if an event handler is synchronous, or async but returns a completed task immediately, which is quite common in testing, because dependencies are usually mocked and return completed tasks, then the event handler methods are actually running synchronously and the task that the event trigger methods throw away is thus completed already.

The reason why all the event trigger methods without async prefix just throws away the task is because of the scenarios mentioned above, where an event handler is async and doesn't return a completed task, then doing a Wait() on that would simply block the test in manay cases.

I will see if I can get some time to put together a sample project rather than the slightly vague example above.

No need, I understand your use case now. Thanks for elaborating.