[yast-devel] a stupid UI recorder and player (Re: GUI testing framework)
Hi, here's a first standalone version of the UI recorder and player that I used for profiling the storage UI. It is quite stupid: - The recorder records certain UI calls into a recording file (YAML) - The player intercepts a smaller subset of those calls, and if the arguments match, supplies the answer from the recording. https://gist.github.com/mvidner/b5498d2ce5c6b1a484a4dca8dd7bdbd3 It has worked for me to reproduce simple interactions with yast2 host and yast2 timezone. Now let's see if it's actually useful. -- Martin Vidner, YaST Team http://en.opensuse.org/User:Mvidner
Dne 19. 10. 18 v 17:46 Martin Vidner napsal(a):
Hi,
here's a first standalone version of the UI recorder and player that I used for profiling the storage UI.
Thanks! It's an interesting idea, simply overriding the UI.* methods... But the biggest drawback is that it does not check the current UI status, it blindly sends the user actions in the same sequence. Which means if the sequence is a bit different than expected it might get out of sync. For example some modules ask to install missing packages at the beginning in a popup. So the sequence might be :yes, :next, :next... If the packages are already installed or you run the module again then popup can be skipped and sending :yes in the first UI.UserInput call will be wrong. Some dialogs ignore unexpected values, but some raise an exception which means it might crash... A similar problem exists with the widget status, imagine a button which in the initial run is enabled so clicking it is recorded. But in the second run for whatever reason it is disabled, then the mocked UI.UserInput would still return the recorded click although in reality the user would be unable to click it. So this Recorder/Player makes sense in a controlled environment where you can be sure the workflow will be always the same. BTW that "host" client example mentioned in the file header displays an empty table when playing the recorded session. The reason is that the player also stubs the UI.ChangeWidget which initializes the dialog content. Any reason for this? It looks strange that later it sends actions for items which are not displayed in the real UI. And there is no delay between the replayed user actions, if you play the recorded session it might finish almost immediately so you do not know if it succeeded or crashed ;-) I'd propose to use something like this https://github.com/lslezak/cucumber-yast/blob/master/features/support/env.rb... so you can optinaly watch the dialog reacting on the simulated user actions. Anyway, I still can see an use case for this. When testing a fix sometimes it's annoying after each change to navigate to the testing dialog or to fill the testing data (esp. values like an email and registration key). If I could simply do some initial input automatically and then continue with the testing manually it could save me some boring work. So maybe we could put the script with some documentation or examples into the yast2-devtools ?? Or https://github.com/yast/helper_scripts ? -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8
V Tue, 23 Oct 2018 17:24:38 +0200
Ladislav Slezak
Dne 19. 10. 18 v 17:46 Martin Vidner napsal(a):
Hi,
here's a first standalone version of the UI recorder and player that I used for profiling the storage UI.
Thanks! It's an interesting idea, simply overriding the UI.* methods...
But the biggest drawback is that it does not check the current UI status, it blindly sends the user actions in the same sequence. Which means if the sequence is a bit different than expected it might get out of sync.
For example some modules ask to install missing packages at the beginning in a popup. So the sequence might be :yes, :next, :next... If the packages are already installed or you run the module again then popup can be skipped and sending :yes in the first UI.UserInput call will be wrong. Some dialogs ignore unexpected values, but some raise an exception which means it might crash...
A similar problem exists with the widget status, imagine a button which in the initial run is enabled so clicking it is recorded. But in the second run for whatever reason it is disabled, then the mocked UI.UserInput would still return the recorded click although in reality the user would be unable to click it.
So this Recorder/Player makes sense in a controlled environment where you can be sure the workflow will be always the same.
BTW that "host" client example mentioned in the file header displays an empty table when playing the recorded session. The reason is that the player also stubs the UI.ChangeWidget which initializes the dialog content. Any reason for this? It looks strange that later it sends actions for items which are not displayed in the real UI.
And there is no delay between the replayed user actions, if you play the recorded session it might finish almost immediately so you do not know if it succeeded or crashed ;-)
yes, but it is really helpful for initial purpose - profiling of program with given sequence of commands, where it was very helpful.
I'd propose to use something like this https://github.com/lslezak/cucumber-yast/blob/master/features/support/env.rb... so you can optinaly watch the dialog reacting on the simulated user actions.
Anyway, I still can see an use case for this. When testing a fix sometimes it's annoying after each change to navigate to the testing dialog or to fill the testing data (esp. values like an email and registration key). If I could simply do some initial input automatically and then continue with the testing manually it could save me some boring work.
Yes, especially for installation, when you need to fill reg code, select multiple extensions and reg codes for them. Or for expert partitioner, where doing some bigger RAID is now pain ( will be hopefully better with planned wizards )
So maybe we could put the script with some documentation or examples into the yast2-devtools ?? Or https://github.com/yast/helper_scripts ?
Good idea, maybe even devtools so it can be installed as RPM. BTW, I think we should really have single git repo for all utility/scripts/helpers. Searching three possible locations is a bit annoying. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (3)
-
Josef Reidinger -
Ladislav Slezak -
Martin Vidner