On Fri, 2013-11-08 at 11:43 +0000, Gordon Sim wrote:
> ...
> > Option 1:
> >
> > Add a thin layer (new test) to check language preference and pass control 
> > to the corresponding test. In this case existing tests are preserved and 
> > continue to exist in the language specific source trees. The disadvantage 
> > is that we end up maintaining similar code in multiple places.
> 
> I'm strongly against this option.

I absolutely agree.


> Option 3:
> 
> Consolidate the tests into one source and place it in qpid/python. I.e. 
> consider the benchmark script to be part of (or related to) the python 
> client much as the qpid-python-test script is.

This makes a lot of sense to me too

> 
> Since both the existing tests already import qpid.messaging this isn't 
> actually imposing any significant extra dependency. There are also 
> python equivalents of qpid-send and qpid-receive.
> 
> Providing we keep the ability recently added to qpid-cpp-benchmark to 
> specify the path to qpid-send and qpid-receive, that test can then be 
> used to run either c++ or java based equivalents.

One disagreement I may have here is that I think we should retain
different names for the different implementations of qpid-send and
qpid-receive. So I think we need to add an option to qpid-benchmark to
not only set the path it uses to find them, but also the names of the
executables it uses. An approach the works for the Java testing is to
use "profiles" that set a bunch of related parameters and that can be
switched as a whole.

The reason I want to do this is that I want to move to a testing regime
where we can run a specific build and use its install result (with
probably a special testing tools install location) to run the subsequent
test run. If we are to do this with multiple of the the qpid subtrees
together, say c++ and java then it will be confusing if the *-send and
*-receive executables have the same name.

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to