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 Tue, 06 Mar 2007 14:58:29 GMT
Working copy of the spec is now at:

http://cwiki.apache.org/confluence/display/qpid/Interop+Testing+Spec.

This describes the centralized approach advocated by Gordon. One
important difference with Gordon's proposal is that the assign role
(and some other control messages) are not sent out on a fanout
exchange like he describes, but on a topic exchange instead. This is
because there may well be a pure JMS test client, and the JMS
implementation only talks to direct and topic exchanges, not fanout.
Also, I'm thinking that for each test case instance there will only be
one sender and one receiver client (although the receiver may be asked
to open multiple connections for pubsub tests), whereas Gordon's
solution was a bit more general purpose in that their could be many of
each. I've been carefull to make sure the many of each approach is
still viable, by mandating the use of correlation id's in test
conversations, so that receivers can disambiguate senders in a many to
many type test. Left as a future direction for the spec.

Don't like something in the spec? Its a working copy, not set in
stone. I expect we'll discover a few things along the way and need to
adapt which is fine. I'm thoroughly bored of writing it now, time to
write some code.

Rupert

On 3/5/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> 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
> ok?
>
> Producing updated working interop spec, with a view to putting it on
> the wiki later today.
>
> Rupert
>
> 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
> > echo QPID_HOME=$QPID_HOME
> >
> > 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.
> >
> >
>

Mime
View raw message