V Tue, 23 Oct 2018 17:24:38 +0200 Ladislav Slezak <[email protected]> napsáno:
> 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#L38-L42 > 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: [email protected] To contact the owner, e-mail: [email protected]
