Re: [lmi] Headless GUI tests

[Vadim Zeitlin]

On Sat, 13 Nov 2021 18:24:25 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 11/13/21 5:37 PM, Greg Chicares wrote:
GC> 
GC> [...need to ^C because GUI test doesn't terminate normally...]
[...]
GC> and now, after all the output above:
GC>   xwud -in /var/tmp/Xvfb_screen0
GC> shows something that may actually be useful. What I see is:
GC>  - a small background window with a "File Census Test Window" menubar.
GC>      and "Added cell number 7." on its statusbar; and, on top,
GC>  - a foreground window saying:
GC>      "[blue '?' icon] Do you want to save changes to unnamed15?"
GC>      "Yes No Cancel"
GC> Everything else is just a black background, except that an "x" graphic
GC> (black with white border, looking much like a close-button graphic),
GC> several lines below the word "number".
GC> 
GC> If I run that 'xwud' command repeatedly while the GUI test is
GC> running, I see numerous screenshots that look like what I'd normally
GC> expect when running non-headlessly.
GC> 
GC> If I wait a couple minutes after "NOTE: 4 tests were skipped", then
GC> I still see the "Yes No Cancel" stuff described above.
GC> 
GC> If I run 'xwud' after ^C-ing the GUI test, I see a black screen.
GC> 
GC> This may be enough information for me to find and fix whatever is
GC> going wrong.

 Unfortunately I still can't reproduce the problem, and I couldn't manage
to understand how could it happen from reading the code neither. The dialog
you see is shown by wxDocument::OnSaveModified(), and is expected, because
the document is indeed modified. In fact, it's so expected, that there is
special code for dealing with it in the dtor of wx_test_document_base which
ensures that the document is closed after selecting "No" in the dialog if
it appears.

 As we have an object of wx_test_new_census class in the paste_census test
and this class inherits from wx_test_document_base, destructor of this
class should be executed in any case, whether the test succeeds or fails,
and so normally this dialog should never remain shown.

 Except that it does remain, of course, and so there must be some
explanation, preferably not involving any supernatural forces. I thought
that perhaps the document was actually not modified yet when
wx_test_document_base::do_close() was executed, so that the dialog doesn't
appear at this moment, but becomes modified later, due to some events
modifying it being dispatched from wxYield(). But this doesn't seem
possible neither, because why would the dialog appear if we didn't call
Close()? And if we did call it, then we must have dispatched the Ctrl-L
event generated by do_close(), and then we must have already dispatched any
previous events too, because, as unpredictable as event dispatching is, we
should be able to count on it being sequential, with no (command) events
jumping in front of the queue.

 So it would seem that the dialog could only possibly appear if we called
wx_test_document_base::close(), but this is only called at the end of
paste_census test and we don't get there in case of the assert failure.
Besides, if we did, a dialog constructed without any wxExpectModal in place
should be caught by the "expect_no_dialogs" object created in
SkeletonTest::RunTheTests(), and result in an error message.

 IOW I think I have conclusively demonstrated that what you're seeing is
impossible. Knowing that it clearly is, where is the mistake in my
reasoning?


 The only positive thing is that I'm pretty sure that I found at least
something which is definitely wrong: that "expect_no_dialogs" object that I
mentioned above is actually misnamed and would have been more accurately
called "expect no dialogs until we close the last window" because it is
destroyed before the (appropriately named) "close_top_window_on_scope_exit"
object in the same function. We need to exchange the order of creation of
these 2 objects in order for the "expect_no_dialogs" one to catch any
dialogs coming up while we close the window. This is, of course, not the
case here, as you see the offending dialog before we start closing the main
window, but I think it's still worth applying the changes from  PR 197[*]
corresponding to the "detect-dialogs-in-gui-test" branch in my repository.
This is not going to (or at least should not, although one never knows,
with supernatural forces) change anything for the problem at hand, but
could save us some head-scratching in the future.

[*]: https://github.com/let-me-illustrate/lmi/pull/197

 I'll keep thinking and trying to understand what's going on with this
dialog, but right now I just have no ideas any more, after spending a few
hours (!) on this already today, so I think it's not really productive to
continue with it today, sorry.

VZ

pgpt6c0M5FutV.pgp
Description: PGP signature