Move to an async first API

[SimonCropp]

[egil]

You might want to check #757. Seems related. I assume this is not for merging.

[SimonCropp]

@egil

So this was an experiment to see is i could get it all working in an async manner. There are still a few more items to do, but i think this stands as a proof of concept.

Why:

• we already have async tests. so the value of bunit being "mostly not async" has little value for us
• we get intermittent deadlocks when calling bunit APIs. usually when using the WaitFor* methods. I havnt raised them since it is very difficult to repro
• Most commonly, when we do a render, we dont want to execute the next line until the render is complete. so we want to await it

I assume this is not for merging.

So yes i think this should be merged, and think is should be the approach used in the next major of Bunit

[SimonCropp]

note i took a few liberties to get it building on my machine. if you decide to accept this approach. i will clean them up

[egil]

Ok, we have a few major things right now planned for v2 (code will live in the v2 branch).

• drop support for netstandard2.1 and NET5
• build and update DOM tree directly in AngleSharp
• use single synchronization context for both test and renderer. That should solve race conditions between test code and renderer code, for which we currently have a whole bunch of complex logic around, like locks.
• switch to async versions of WaitForXxx methods and introduce a async version of Render (see linked draft PR).

The last point is related to what you are doing, but I have started with building and updating DOM directly, since that will have the biggest impact on the TestRenderer.

I appreciate your efforts, but won't promise we'll take this PR as is and merge it. But we'll definitely look through it and see what changes you have made and include the parts we can reuse.

[egil]

we get intermittent deadlocks when calling bunit APIs. usually when using the WaitFor* methods. I havnt raised them since it is very difficult to repro

Does this still happen with the latest release?

If so, I would appreciate it if you can run your test in CI with the --blame-dump switches (see our verification workflow) and save any dumps you get so we can investigate and fix these issues for V1 as well.

This dump files allows me to see the exact place where two or more threads are stuck and usually gives me a good idea for how to fix it.

[egil]

Im going to close this Simon. Thanks for your suggestions and input on this. For V2 of bUnit, which are in the works, there will be async APIs added where it makes sense. In particular, there will be async Render/RenderComponent methods as well as event handler trigger methods such as Click, where the behavior will be adjusted to work better.

Once the V2 branch have these changes, we'll see about back porting them to V1, if that's possible to do in a non-breaking manner.