Hey there, i am write a component that handles it’s own Message type and update function. The update function returns for async-processing Task. My question is now, how is the desired way to implement testing here? I need than an async runtime handling the results coming from the update function call of the single component. Nevertheless, this would mean, i have to implement a ton of Task execution functionality, that the iced runtime has already in place.
So my question boils down to: How do i use the iced async runtime inside component tests, that i can avoid implementing task execution on my own? Does this come down to something like starting the full application in some kind of headless mode, to be able to provide the central message channel and async runtime? But then: how? Is there somewhere an example already doing this in a test setup? Does this potentially relate to alot of work currently going on for iced 0.14 milestone?
Thanks for pointing out the simulator in this example. It is tackling a different part of what i want to test, but important to know about. Thx. I think, i have to think more clearly on what i want to test exactly.
At the moment i have a component, that spawns out an async stream via Task::stream where i continously yield messages into the event channel. In general i use the update function of the component like a translation table for states of the component, where some of the translations are async and long running. Those start then by producing the next propper Message the equivalent state change of the component.
Nevertheless, to really run through such state changes, i have to execute the tasks by the update function of the component. Since i produce alot different onces, e.g. Task::done, Task::stream, Task::batch, etc. i would have to implement alot of aspects of the iced::runtime to handle the message channel and all the different types of Task execution.
My point is there, if the iced tests are providing some functionality to get the runtime itself without setting up the full application or to run at least the application in headless mode.
Ok i look into that in more detail. Maybe it is already what i want to achieve here. What i do not see in the example, is how the simulator would handle the Tasks if the update function returns Task instead of Message directly. Would the simulator already handle the asynchronous execution of the Tasks and then provide the messages? If this is the case, it would be the perfect fit of what i am searching.
if I understand correctly, you are looking for iced_runtime::task::into_stream. it takes your Task<T> and returns Option<BoxStream<Action<T>>> that you can consume it and iterate inside a simple async test (like #[tokio::test]). If you test your own component that should be enough, because, in the most cases, your async tasks are futures / streams. But if you try to test something like widget::operate then (i’m not sure, but I think) there is no simple way to do that without an iced runtime because only the runtime knows about your widget tree.