Some newbie questions...

[J.T. Conklin]

I have been experimenting with QMTest, have read the manual, and have
gone through the tutorial.

I have hopes that QMTest will enable my project to follow through on
good intentions of having a good testsuite.  There have been efforts
in the past (primarily a hoge-poge of unit tests, each with it's own
mechanism for reporting success/failure), the lack of an framework has
lead to the tests not being run and eventually to test bitrot.

While the manual is pretty good at explaining what can be done, it is
a light on general recommendations for making an effective testsuite.
Part of this is the nature of a flexible framework, but there must be
some best practices that are applicable to wide variety of
applications.

* 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).

* 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.

* 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.

        --jtc

-- 
J.T. Conklin