[qmtest] Executable paths and working directories

[Nathaniel Smith]

On Fri, Jan 03, 2003 at 01:26:33PM -0800, Mark Mitchell wrote:
> --On Friday, January 03, 2003 03:51:34 AM -0800 Nathaniel Smith 
> <njs at uclink4.berkeley.edu> wrote:
> 
> >In our (envisioned) setup, we have tests written in C++ that get
> >compiled more-or-less alongside the source code they're testing, and a
> >test database for the whole project that has entries to call the
> >executables that do the real testing.  What I'm wondering is how I
> >should be telling the qmtest Test objects where their executables are.
> >I could always hack something specific into my custom test class (by,
> >say, using some logic to find the root of the build tree, and
> >chdir()'ing there before running an executable specified by a relative
> >path), but it seems like there must be a better and more general
> >solution, and I'm wondering how it would work.
> 
> The GetDatabase() method available in all test classes will let you
> find the root of the database; you do:
> 
>  self.GetDatabase().GetPath()
> 
> So, one solution is to have your test class use that method to get
> at the build directory.

Unfortunately, since build directory != source directory in general,
knowing where the test database is stored doesn't actually help that
much :-(.

> Alternatively, you could use the context to tell you where the
> executables are; that's a perfect application for the context.  (The
> idea of the context is to provide information about the test environment
> that might vary over different testsuite invocations.)

Right, that makes sense to me too.  It still seems like there should
be some more generic way of doing this than defining a special key in
my context and then having my custom Test class look for it.

> The working_directory support that you see littered about in the code
> should actually be removed.  We originally envisioned allowing tests
> to set their working directories, but then realized that does not work
> when running tests in parallel -- working directories are per-process,
> not per-thread.  So, that stuff will be going away as soon as I get
> around to editing the files. :-)

Oo, good point.  Hmm.  So any generic working directory support should
probably be implemented in the various command tests themselves, via
the "dir" argument to Executable.Run.

I think what I'll do for now is add a some sort of "search path" or
"base directory" attribute to my Test class, and % expand it against
the context; that seems a nice balance of genericity, flexibility, and
simplicity, unless anyone can think of a problem with it...

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein

This email may be read aloud.