lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Better error messages for the GUI test failures


From: Vadim Zeitlin
Subject: Re: [lmi] Better error messages for the GUI test failures
Date: Thu, 12 Feb 2015 23:15:59 +0100

On Thu, 12 Feb 2015 18:17:23 +0000 "Murphy, Kimberly" <address@hidden> wrote:

MK> Vadim Zeitlin wrote:
MK> 
MK> Using revision 6109 along with the updated wx trunk designated 
MK> here:
MK>  http://lists.nongnu.org/archive/html/lmi/2015-01/msg00043.html
MK> 
MK> the validate output tests no longer fail:

 I'm glad to hear this and thanks for (re)testing!

MK> Backtracking, the validate output tests had failed for me with 
MK> revision 6086 (and the previously announced wx trunk). So, using 
MK> the updated wx along with revision 6086, I reran the automated 
MK> suite. The validate output tests do indeed fail:
...
MK> validate_output_illustration: ERROR (Assertion failure: Expected 
wxMessageDialog with wxYES_NO style was not shown. [file 
/opt/lmi/src/lmi/wx_test_new.hpp, line 84, in close_discard_changes()].)

 So for some reason the illustration is not considered to be modified...
The most likely explanation would seem to be that the comment was not
entered into the illustration properties dialog correctly but unfortunately
I still have no idea why. A hack that I use to debug mysterious failures
like this is to insert a wxSafeShowMessage("whatever", "doesn't matter")
into some code before the possibly failing operation is executed, i.e.
after showing the dialog in the beginning of
enter_comment_in_illustration_dialog::OnInvoked() in this case. This gives
you a chance to have a look at the screen contents and perhaps you would
notice something untoward that would help us to understand the problem.

MK> The messages have improved. A number of improvements were made 
MK> between revision 6086 and 6109. Can we pinpoint what the issue 
MK> might have been? 

 Unfortunately I've never been able to reproduce it (which is a concern on
its own) and looking at the commits between those two, nothing looks
obviously responsible. If you have the possibility to do it, it would be
great if you could please try bisecting the changes to find the exact
commit that fixed the problem. Unfortunately svn doesn't have native
support for bisecting but there are several third party tools that can be
used for it and, in the worst case, it could be done by hand (there will be
only 4-5 commits to try normally).

 Sorry for lack of more help and thanks once again,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]