Recommended testing tools/framework for GUI automated testing

gui
projucer

#1

Is there any recommened Tools/testing framework available to test JUCE GUI? I couldn’t find more information related to this.


#2

What aspects of the GUI do you want to test?

I’ve not come across a good solution for injecting mouse and keyboard events directly, but it’s relatively straightforward to check the overall visibility of any components at any time. You can also take screenshots of components and test individual pixels.


#3

Button also has a triggerClick() method which you can use to simulate mouse clicks on them.

Unfortunately, I don’t think other widgets provide similar methods to simulate interactions.

Perhaps, if feasible, a better approach could be to have a generic way (free functions?) to simulate gestures on a given Component, by injecting MouseEvents on them.

Something like:

void triggerClick (Component& c);
void triggerDrag (Component& c, Point <int> displacement);

Each of those functions may also be parametrized with more stuff like duration of the gesture, modifier keys, etc.


#4

For triggerClick to work, we need an instance of the button which we would like to click
Getting the instance of button seems to be difficult…


#5

See this: Using Button::triggerClick in a unit test

Still, if you saw Ableton’s lecture I’m not sure how much automated UI tests are worth at least those days. especially with plug-ins where your entire threading and callbacks can be so different between hosts.


#6

I am interested to see what can be done. Currently user-based testing following a script takes of the order of 8 hours to complete for an application I am working with. So having a mechanism that can at least set up each test condition for a human user to evaluate would significantly reduce this time.

I am wondering if a recording mechanism could be set up via MessageManager::dispatchNextMessageOnSystemQueue whereby events could be recorded during a session and played back.

Two problems;

  1. Timer events need filtering out as the app. will be creating them itself and we do not want them to count twice.
  2. Window handles will change between sessions - so a means is needed to convert window handles during the recording session to window handles during the replay session.

Has anyone considered this or a similar approach? A JUCE-centric coded UI testing framework would be good to have in the toolkit.