Kazunobu Kuriyama wrote: > 2017-03-20 5:24 GMT+09:00 Bram Moolenaar <[email protected]>: > > > > > Please note that I changed the client-server test to use timeouts, > > instead oa a timer with an abort. The main reason is that if the abort > > kicks in there is no way to rerun the test, thus adding it to the list > > of flaky tests has no effect. > > > > I also added a check if the remote server is up, by getting the value of > > v:version. That avoids the arbitrary wait time. > > > > I hope you can use this to make the quotestar test more reliable. > > > > So I wrote a patch following your kind suggestion. Please find an attached > patch. Hopefully, it works well on Linux, too.
Thanks, it passes for me, thus I'll include it. > BTW, though this is an off-hand idea inspired by the client-server test... > > If our GUIs have such a function that returns the window ID of a widget of > interest such as a menu item, a toolbar button, a slider, or a dialog > button, and if Vim also has such a function that synthesizes an X11 > keyboard or mouse event and sends it to the window, then it seems that the > client-server test you've just developed last two or three days could give > us a good model which makes feasible some kinds of GUI tests which have > been difficult to implement. > > More specifically, say, suppose a hypothetical menu test: > (1) Have a vim instance (= client) create a vim server and have the latter > launch the GUI. > (2) Have the client query the server about the window ID of interest using > one of the hypothetical functions mentioned above. (Note that this > requires that menu items must be realized before the query.) > (3) Have the client get the server to pop up a menu using, say, :call > remote_send(server, ":popup File"), (Note that, after popping up a menu, > the server can't return to the event loop until someone closes the menu. > Hence the order of (2) and (3) matters.) > (4) Have the client synthesize an X11 event and send it to the window using > another hypothetical function mentioned above. > (5) Check the result. > > I need to look into that further; some of the assumptions I took for > granted might be wrong, and hence the whole story might not be that simple. Hmm, this might work. But we should also look into a more generic way of remote-control testing. I believe neovim does this, I never looked into how this works, what tools are required, etc. There are several tests which are difficult to do inside the running Vim. Especially grabbing text on the screen, checking where the cursor is, etc. At the same time, my experience with remote testing frameworks is that they are very slow, unreliable and require a lot of maintenance. Perhaps I was just using the wrong one :-). -- Living in Hollywood is like living in a bowl of granola. What ain't fruits and nuts is flakes. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
