Improved automated testing

[williamhammond]

Hello everyone.,I asked in Zuplip and someone mentioned it doesn't exist and would be useful so I figured I'd open a ticket.

I think it'd be nice if there were some sort of way to setup tests where an Application can be fed input and the state of the Application could be introspected and compared against an expected state.

I think the primary issue with implementing this is the fact Application::run takes control of the current thread. I'm not sure what communicating to the application from a different thread would look like but if there is a clean work around what about an interface that might work like changing the result of Application::run from Result<(), Error> to Result<Application, Error>. Assuming the startup went well, we'll have access to Application and from there we could use update and make assertions based off State?

This might be a little naive, since I'm beginner and my app is currently only a single widget 😅 but it'd be a big benefit for automated cross-platform testing.

[13r0ck]

The current method would be decoupling "pure" data from "GUI state". This was also recently covered on Zulip.
Just copying and pasting that chat over here

From Hecrj:

> I think decoupling pure data from GUI state is a good idea. However, that does not mean your GUI cannot contain data. You can write a mapping from pure data to GUI state and viceversa.
> Say you have a User but you are building a profile edit form. You can turn that User into an EditForm screen and once the form is saved, return a User again.
> The important part is to avoid duplicating the sources of truth.
> In other words, don't store both the User and the EditForm in your application state because that means you will have to synchronize them. Instead, only have one representation of a set of data at any given time.
> This is less convenient, but generally will lead you to better code.
> Say your application is listening to some User attribute that can change, if you only have one source of truth for the User data, then your update logic will have to be able to update both a User and an EditForm.
> Because your current user won't always be in User form. Not sure if I'm making any sense.
> Avoiding duplication of sources of truth is not always possible or practical, so it's a tradeoff really.
> You have to consider your use cases before modelling your data.
> If synchronization is not a concern, then duplication may be okay.

From me:

> Why is decoupling generally better code, is it for performance, read-ability, code flexibility, all 3, something else?

From Hecrj about the use case for testing:

> Generally I like to solve problems as isolated as possible without having to think about presentation first.
> Then presentation is like a layer on top of that.
> This boundary helps with unit testing.
> Some call it "business logic" or "domain logic" but I find most of the patterns related to these concepts overly complicated.
> I think it's all reduced to using the proper data model for every use case.
> Your core logic has different use cases than your presentation logic.
> Therefore, you probably need different types for each.
> And then some kind of mapping between them.
> If you try to reuse types everywhere, you will end up with a blurry boundary and types that do too much without any cohesion.

I do agree though, long term it would be fantastic to have an iced feature that would launch the application in testing mode. Something like iced = { ~~~, features = ["tests"]} that would after compiling run user written tests on the app.