Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved unit/regression test support #3926

Open
oscargus opened this issue Jan 31, 2024 · 2 comments · May be fixed by #5166
Open

Improved unit/regression test support #3926

oscargus opened this issue Jan 31, 2024 · 2 comments · May be fixed by #5166
Assignees

Comments

@oscargus
Copy link
Contributor

Is your feature request related to a problem? Please describe.

To improve regression testing, it would be nice if there is was a mechanism to "inject" mouse and keyboard presses from code. (I guess there may be, just that it is not that simple to figure out how.)

Describe the solution you'd like

Ideally a testing framework to make it easier to test egui applications. However, a clear described mechanism to force certain events would be a first step.

Describe alternatives you've considered

Additional context

This is somewhat related to #1129 (we are using egui-skia to generate test images, but can only test features triggered by messages, not "pressing" keys/mouse buttons in suitable areas).

@molenick
Copy link

What current test strategies exist for egui applications? I'm looking to feature/system test an app using egui and am lookong at where to start.

I'm coming from web where interfaces are pretty easy to test since assertion against DOM state is trivial/well supported.

@oscargus
Copy link
Contributor Author

Not sure if is counts as a test strategy, but in Surfer we use egui_skia https://github.com/lucasmerlin/egui_skia (but a local version that supports egui 0.25, we still need to add support for 0.26) and generate images that we compare. See https://gitlab.com/surfer-project/surfer/-/blob/main/src/tests/snapshot.rs?ref_type=heads

Limitations are (among others):

  • We can only trigger responses based on messages, so we cannot really "press" buttons, just send the message that the button press hopefully would generate.
  • We can only test visual responses, not checking that a particular variable was changed (now, this is probably more tricky in Rust than in Python that I'm more used to), which leads to an excessive number of images and to some extent redundant code if one would like to check the outcome for each of a sequence of actions.
  • Every related to keypresses (we have a command line popping up where one can trigger messages in addition to shortcuts) cannot really be tested.
  • Mouse actions cannot be tested.
  • Editing text displayed in e.g. dialogs (that we open to make sure that they "work") leads to new images, oxipng https://github.com/shssoichiro/oxipng is helpful to reduce the size of the images, but still the repository fills up with old images.

Still, it gives us some code coverage and tests have helped us from breaking stuff unintentionally so we think it is worth it.

@lucasmerlin lucasmerlin self-assigned this Sep 24, 2024
@lucasmerlin lucasmerlin linked a pull request Sep 25, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants