[qmtest] Some newbie questions...

[Mark Mitchell]

> * Are there any recommendations for the use of QMTest with a code
>   control system -- especially those unlike CVS where an explicit
>   "edit" command must be used before changing files.  There is no
>   indication that a change will fail (within the GUI) until you
>   OK the changes, where QMTest fails with a python exception (because 
>   of the read-only test file).

There's no recommendation for that.  It would be nice if QMTest did
better than report the Python exception, though!

> * Are there any recommendations for the location of executables used
>   by tests?  Our unit tests are currently built in the same
>   subdirectory as the code that implements the module.  Using absolute
>   paths to the test executables does not work, as every engineer has
>   their own sandbox; Using relative paths does not work because QMTest
>   seems to change directories as it executes.  We could set the PATH
>   to include all of the modules in our makefiles (actually SConscripts
>   in our case) or maybe have a QMTest wrapper, but that seems pretty
>   clumsy.

QMTest (as of relatively recent versions) does not change directories as
it executes.  It used to (in QMTest 1.x), but does not in QMTest 2.x. 
So, relative paths should work.

> * The canned Exec tests cause the test program to inherit environment
>   variables.  These semantics seem to be just asking for testsuites
>   that behaves differently for different users.  If I understand the
>   concept of test classes correctly, I think I can get around this 
>   by subclassing ExecTestBase and overriding MakeEnvironment, but it
>   seems odd that this is necessary.

We used to think as you do. :-)  However, on many systems some
environment variables (like LD_LIBRARY_PATH on GNU/Linux) must be set or
nothing will work at all.  Therefore, we decided to simply propoagate
the environment.  You are correct about how you can solve the problem.

-- 
Mark Mitchell <mark at codesourcery.com>
CodeSourcery, LLC