Uhh I still think it's very verbose with those long names. I do think await cut.AssertionAsync() reads well, but its not aligned directly with the existing methods.

await cut.AssertionAsync();
cut.WaitForAssertion()

Both code lines contain the word "wait".

The thing is though, the name isn't telling the truth thought, we're not a awaiting an async assertion. The assertion is not async.

Uhh I still think it's very verbose with those long names. I do think await cut.AssertionAsync() reads well, but its not aligned directly with the existing methods.

await cut.AssertionAsync();
cut.WaitForAssertion()

Both code lines contain the word "wait".

The thing is though, the name isn't telling the truth thought, we're not a awaiting an async assertion. The assertion is not async.

For now we also could make the WaitForXXXAsync internal and only we're consuming those methods in tests. That gives us time to find edge-cases and we don't have to find a name on the spot.
I know that isn't the most optimal solution but a working set we can built on.

Uhh I still think it's very verbose with those long names. I do think await cut.AssertionAsync() reads well, but its not aligned directly with the existing methods.

await cut.AssertionAsync();
cut.WaitForAssertion()

Both code lines contain the word "wait".

The thing is though, the name isn't telling the truth thought, we're not a awaiting an async assertion. The assertion is not async.

For now we also could make the WaitForXXXAsync internal and only we're consuming those methods in tests. That gives us time to find edge-cases and we don't have to find a name on the spot.
I know that isn't the most optimal solution but a working set we can built on.

Good idea. Let's make this internal for now.

Good idea. Let's make this internal for now.

Said and done! I am very inclined to say on v2 there is no sync version of this particular API anymore. That would also enables us to remove the TaskCompletionSource completely and just rely on Task.Delay and Task.WhenAny. Maybe I experiment with that as well.

Edit 1: In general I would like to expose more of the async nature of Blazor to the public surface. I don't think we do ourselves a big favour with all the GetAwaiter().GetResult(); code. I do understand the good intention, but asynchronous tests are also very normal nowadays^IMHO.

Edit 2: By the way with only the change of WaitForXXX to WaitForXXXAsync our tests are way more stable making my thought about a more asynchronous API even stronger.

I agree. Been battling too many edge cases in the name of simplicity.

But that's for V2 🙂

Does it make sense to keep the sync versions of the tests around as well as the new async versions?

This would allow us to see if the async versions are indeed more stable over time, I think.

Correct me if I am wrong, but what you want to see with that, ist that the Async version isn’t failing where as the sync version will be failing from time to time(behavior as off now)?

if so I am not sure if we would see that picture even if Async makes it more stable. The reason might be that thread starvation is still a thing.

Besides all the tests in RenderFragmentWaitForHelperExtensionsTest are still using the sync version. Would this be good enough?

Does it make sense to keep the sync versions of the tests around as well as the new async versions?
This would allow us to see if the async versions are indeed more stable over time, I think.

Correct me if I am wrong, but what you want to see with that, ist that the Async version isn’t failing where as the sync version will be failing from time to time(behavior as off now)?

if so I am not sure if we would see that picture even if Async makes it more stable. The reason might be that thread starvation is still a thing.

Besides all the tests in RenderFragmentWaitForHelperExtensionsTest are using the sync version. Would this be good enough?

I think it would be worthwhile to have both test sets around for a while to get an indication of the effectiveness of the change. We could simply have to calls to dotnet test in our verification workflow, one that runs with the filter argument where the sync tests are filtered out and one where the async tests are filtered out.

Does it make sense to keep the sync versions of the tests around as well as the new async versions?
This would allow us to see if the async versions are indeed more stable over time, I think.

Correct me if I am wrong, but what you want to see with that, ist that the Async version isn’t failing where as the sync version will be failing from time to time(behavior as off now)?
if so I am not sure if we would see that picture even if Async makes it more stable. The reason might be that thread starvation is still a thing.
Besides all the tests in RenderFragmentWaitForHelperExtensionsTest are using the sync version. Would this be good enough?

I think it would be worthwhile to have both test sets around for a while to get an indication of the effectiveness of the change. We could simply have to calls to dotnet test in our verification workflow, one that runs with the filter argument where the sync tests are filtered out and one where the async tests are filtered out.

Yes it does, so let’s do it!

It would also be awesome to create async versions of the RenderFragmentWaitForHelperExtensionsTest tests too.

It would also be awesome to create async versions of the RenderFragmentWaitForHelperExtensionsTest tests too.

Yeah did so. Basically worked with Traits so we can re-use this for the other async helpers as well.
I marked methods also with a. _Sync suffix or in the case of RenderFragmentWaitForHelperExtensionsTest I created a separate class with async in its name.

I also introduced a new step to separate sync/async in our CI/CD pipeline.

Edit: I am running always all the tests in both cases, so we can see if other tests cause issues as well. I do think if we run sync or async in isolation, we don't have the full picture.
Yes it will increase the build-time, but this is anyway only temporarly.

Awesome. Good work on this.

Sorry there is a merge conflict, will resolve it in a minute.