lmi
[Top][All Lists]
Advanced

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

Re: [lmi] wx_test_about_version.cpp


From: Vadim Zeitlin
Subject: Re: [lmi] wx_test_about_version.cpp
Date: Sat, 6 Dec 2014 16:04:35 +0100

On Sat, 06 Dec 2014 14:48:48 +0000 Greg Chicares <address@hidden> wrote:

GC> /// Validate version string (timestamp) from "About" dialog title.
GC> ///
GC> /// Test that the version string matches the timestamp specified in
GC> /// 'version.hpp'. That's not a really useful test because it can
GC> /// hardly fail, but it's so inexpensive that there's no reason to
GC> /// delete it.

 No questions about this part.

GC> /// Write the version string to stdout (along with other test output)
GC> /// for comparison with previously-saved results.

 I'm not totally sure if this is supposed to be the full dialog title, just
the last word of it (which is supposed to be the date) or maybe the two
last words ("version" + date)?

 So far I did

        wxLogMessage("About dialog title is \"%s\".", d->GetTitle());

which results in something like this on output:

        About dialog title is "About 'Let me illustrate...' version 
20141016T2306Z".
 
Please let me know if this needs to be changed.


GC> /// Find the last copyright year listed in the dialog's client area,
GC> /// and compare it to the year in the version string, and also to the
GC> /// current calendar year: it should match both. (This means that
GC> /// running a 2014 GUI test in 2015 will fail; that's okay.) Monthly
GC> /// releases sometimes update only the 'expiry' file, but reuse the
GC> /// last month's binaries with an unchanged version string; therefore,
GC> /// only the version string's year is compared to the current date,
GC> /// whereas month, day, and time are not.

 I've already implemented this locally, but I'm not totally sure that I did
this right because there is a balance to be found between checking as much
as possible and being as forgiving as possible. I.e. I could check that the
years are actually consecutively increasing numbers. Or, on the contrary, I
could forget about all the preceding years and just look at the last number
found in the string. The latter seems a bit dangerous to me, so, finally, I
implemented a compromise solution which searches for

        (?:\d{4}, )+(\d{4})

regex and uses the match as the year. Does this seem correct to you or
would you prefer something more or less strict?


GC> /// Press the pushbutton to read the license, and check that the
GC> /// license's dialog box is scrollable--to guard against this problem:
GC> ///   http://lists.nongnu.org/archive/html/lmi/2010-01/msg00001.html

 This is the really problematic part. We can open the dialog, of course.
Scrolling it is easy as well if we can only test doing it using the
keyboard and not the mouse (which would be much trickier). But verifying
that it actually scrolls is a whole different problem. I have basically no
idea about how to do it... We could query the window for its scrollbar
position, but this is not the same as ensuring that it actually scrolled
its content. Is it worth spending more time on this, with uncertain
results? Or maybe we could drop this part of the test or, perhaps, just
limit it to verifying that opening the licence[*] dialog works?

 Thanks in advance,
VZ

[*] I do use the US spelling in the sources for consistency, but it's a
    struggle... My fingers just want to write it "right" and I let them
    do it at least in the email text.

reply via email to

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