qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Draft Interop Testing Spec - Please Read
Date Mon, 05 Mar 2007 10:21:34 GMT
Alan, thanks for the scripting advice. Will definitely follow your
lead here as you seem to have a clear idea of how you want this to
work and how to make it convenient to use.

As for gathering reports, I was thinking that each test (sender part)
would report pass/fail (message body containing reason for failure in
failure cases) to the coordinator, of which there is only one, and it
will write out the xml reports. Reason for that being that the code to
write the reports only needs to be written/maintained in one place.
Was also thinking of adding the requirement that each test client talk
to the coordinator over a seperate AMQ connection to that which is
sends its test messages over. The idea being, that if a test failure
causes closure of the connection, it should still manage to send its
report. A more serious melt-down that causes the test client to
completely fail, should still result in the test report being written
out as a fail, because the coordinator knows which tests/clients it
started -> which ones did not produce a report -> which ones to write
out a failure for. So no covered tracks. In this case, look in the log
for the dead test client to figure out what happened. Does this sound

Producing updated working interop spec, with a view to putting it on
the wiki later today.


On 3/2/07, Alan Conway <aconway@redhat.com> wrote:
> On Tue, 2007-02-27 at 20:43 +0000, Marnie McCormack wrote:
> > Not too sure how to completely get round some system variables being set for
> > the tests to run. For example, if you don't set JAVA_HOME or similar, how
> > can you run the java command ?
> JAVA_HOME is Suns fault not ours ;) but you can run Java without
> JAVA_HOME based on PATH - e.g. the standard gcj install works like that.
> Our test suite should work either way.
> > Can Alan or someone shed
> > some light on how the scripts would work without some info about QPID_HOME
> > type stuff ?
> Scripts (programs in general) can figure out where they themselves are
> installed and find their config files etc. by looking relative to that
> without using env vars. E.g. add this as qpid/interop/qpid_java_env:
> #!/bin/sh
> export SCRIPT_DIR=`dirname $0`
> ROOT=`dirname $SCRIPT_DIR`
> export QPID_HOME=$ROOT/java/bin
> export PATH=QPID_HOME/bin
> # etc...
> Now an imaginary test script first sources the environment as follows:
> #!/bin/sh
> # qpid_test
> source `dirname $0`/qpid_java_env
> Finally I put /home/aconway/svn/qpid/interop in my path, now I can call
> qpid_test from anywhere and it always prints:
> [aconway@scooter /]$ qpid_test
> QPID_HOME=/home/aconway/svn/qpid/java/bin
> So now the user has only one thing to set - PATH - instead of 2 or 3,
> which is important if you work in multiple checkouts and need to switch
> easily from one to another. You can also run tests from a different
> checkout *without* setting paths by simply saying:
>  /home/aconway/svn/qpid2/interop/run_test
> and automatically the environment is set for /home/aconway/svn/qpid2
> (NB: the example above fails if you are in a subdirectory of qpid and do
> something like ../../interop/run_test, a slightly more complicated
> script can handle that case too.)
> > Once the spec is agreed (probably we need to draw a line in the sand
> > somewhere here ?) I think we need to:
> >
> > - document on the wiki
> > - prioritise some elements
> > - split into compact JIRAs, by technology, so that individuals can pick up
> > the tasks and contribute (we don't have too many all-code-all-clients people
> > on the project !)
> I'm happy with the proposal so far, once this gets underway I'll try to
> put my code where my mouth is for any further suggestions ;)
> Cheers,
> Alan.

View raw message