lmi
[Top][All Lists]
Advanced

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

Re: [lmi] [PATCH] Add --gui_test_path command line option to the GUI tes


From: Vadim Zeitlin
Subject: Re: [lmi] [PATCH] Add --gui_test_path command line option to the GUI test.
Date: Mon, 15 Dec 2014 16:56:04 +0100

On Mon, 15 Dec 2014 15:40:20 +0000 Greg Chicares <address@hidden> wrote:

GC> I'm thinking of the new developer who downloads the sources, builds the
GC> code, and runs the tests--without any /opt/lmi/gui_test/ directory, and
GC> without the (potentially proprietary) test files it contains. In that case,
GC> I'd like the other tests to run smoothly, without any scary messagebox.
GC> Could you therefore change the messagebox to a reassuring text message on
GC> stdout? Let's say:
GC> 
GC> << "Optional extra tests would be run if any were found in '"
GC> << test_files_path_.native_file_string()
GC> << ", but no such directory exists. Proceeding to run built-in tests."

 This can be done easily, of course, but this message wouldn't be totally
correct, at least not right now. If the code remains otherwise unchanged,
we'd simply use the current working directory instead of /opt/lmi/gui_test
and look in this directory for the miscellaneous input files and if they
are really not there the tests would fail instead of just not being run.

 Granted, this will probably change soon as at least InputSequences.cns and
PasteCensus.cns will disappear completely. I'm not sure about the remaining
ones though: will CoiMultiplier.cns, MonthlyTrace.ill and MecTesting.mec be
not needed neither any longer? If so, I prefer to update the code using all
these files first and then just make the change proposed above.

 Otherwise, i.e. if we are still going to have any tests requiring files in
this directory, it would arguably be better to skip them if this directory
doesn't exist or the required file is not found in it. I.e. I'm thinking of
making get_test_file_path_for() throw test_skipped_exception if the file is
not found. Do you think this would be [more] useful?

 Thanks,
VZ

reply via email to

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