Introduce a crate to write unit tests of Dioxus apps

[hovinen]

This is a preliminary version of a library in the spirit of React or Flutter to allow easy unit testing of Dioxus apps.

Right now it only supports the click event, but I believe that is sufficient to show the design. Once the overall design is finalised, it can be fully fleshed out.

I placed this directly in the Dioxus repository. I'm also fine with keeping it as a separate crate if desired. However, this requires a few small changes to the dioxus-native crate to allow the creation of synthetic events. Otherwise the existing visibility restrictions make it impossible to dispatch DOM events from the test.

I decided to add fairly fleshed out documentation including doctests so as to illustrate the use of the library. I have tested it against a personal project and it is working quite well.

Alternatives considered

• Writing a new renderer. I had considered this but found that it would be pretty much a duplicate of the existing dioxus-native.
• Dispatching events via Document::handle_ui_event. This would mean that the events would act more like real user-generated events, where, say, a click happens at particular coordinates and the framework identifies the element which is hit. This would be more "realistic" in the sense that a click on a button which is covered by another element would not hit the button but rather the element covering it. However, the UiEvent enum from Blitz does not support a "click" event and I did not want to create multiple PRs in different repositories for now.

Fixes #5324

[ealmloff]

Very excited about this, thanks for working on it!

Instead of requiring explicit event pumping, we could mimic the Playwright test API and make queries asynchronously run the event loop:

let mut tester = dioxus_test::render(AComponent).build();
// Wait for make-request-button to load and click it to make a network request.
tester.find_by_test_id("make-request-button").click().await?;
// Assert on the state of the UI while the network request is in flight.
expect(tester.find_by_test_id("loading-indicator")).to_be_visible().await?;
// Receive the server response and assert on the state of the UI after the response
// is received and the UI has been rerendered.
expect(tester.find_by_test_id("resolved-content")).to_be_visible().await?;

In some cases, waiting for work and applying a single tick of DOM operations could provide more control over testing, but I think the familiarity of the Playwright-style API and intuitive behavior in the presence of feedback loops with DOM events are typically more important.

For example, onmounted and use_effect will only trigger after the document has applied edits. With the current model, I think that would require rendering, then waiting for a 0ms timeout, then asserting the state has changed based on the onmounted event. If asserting on that state also pumped the DOM, you could just assert the state is correct directly.

[hovinen]

Thanks -- let me try this and see what I can come up with.