Support for Test Driven Development for library users

[SirRegion]

The idea is too add a "framework" (I'm not sure what to call it) to allow users of the library to test the interfaces they created with ratatui.
Currently, this is really hard.
While there is the TestBackend that can be used, it's not really user friendly.
See the widget_list test for an example. Checking if the list has the correct items requires the user to write a lot of boilerplate. They also have to check the white space of the items.
A better solution would be something like

assert_equal(terminal.get_list().items, vec!["Item 1", "Item 2", "Item 3"];

I'm not to sure about the feasibility of this proposal, because I'm "just" a user of the library and haven't looked at the code too closely.

Additional features that would be nice to have:

• Simulated Input (e.g. keypresses)
• Assertions on Blocks instead of the TestBackend

What are your thoughts on this? Would you use a framework like this?

[Nickiel12]

This sounds like a very useful feature, that, when implemented correctly, would allow for actual tests to make sure it works as expected.

But this is a UI crate. If there is a way to pull it off properly and accurately (which I'm sure there is), it is probably going to take a not insubstantial effort and should probably be shelved till post 1.0 for a feature update.

[SirRegion]

You're right that a complete framework with "end-to-end" testing capability (what I initially proposed) would be a lot of work.
However, I took a closer look at the widget code and noticed, that "block-level" assertions would already be possible if the struct fields of the widgets were public.

I believe this is a rater small change and wouldn't break backwards compatibility, while providing some big quality of life changes.

For example, the list widget with public fields would allow tests like this:

//setup
let list = List::new(!vec["Item 1", "Item 2", "Item 3"]);

//test
assert_eq!(list.items.len(), 3);
assert_eq!(list.items[0],"Item 1");

[AntoniosBarotsis]

I feel like making everything public would be a bit ugly for the project. Maybe instead we could add new methods behind a feature that do this. I'm not very educated on Rust or the codebase but here's my 2 cents on this 😅

[Nickiel12]

The biggest issue about making all struct fields public, is that suddenly all changes to existing struct structure, are breaking changes. No matter what you are doing.

[SirRegion]

I do like @AntoniosBarotsis idea of making it method based instead.

@maintainers would you be willing to accept a PR with this approach behind a feature flag? (Maybe marked as unstable, so we can figure out what the best approach is)

[joshka]

There is some related discussion in #619 for a use case for getters that is not unit testing.