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#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. 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
signature.asc
Description: OpenPGP digital signature
