qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Wall <keith.w...@gmail.com>
Subject Ideas to rationalise the Java test profiles.
Date Mon, 04 Jul 2011 10:44:42 GMT
Robbie and I are presently working on QPID-2811 and QPID-2815.  These Jiras
will rationalise the transport mechanism in Qpid and to allow client/broker
to be tested together within the same JVM regardless of transport.

It seems to me that now is a good time to review the test-profiles.  I see
the following problems:

1) 'default' profile being 0-8 makes little sense as most of the project's
development focus is on 0-10, and with the removal of the old .NET client,
we have no client that defaults to 0-8.
2) The time taken to run some test profiles is excessive and this is a
disincentive to developer good practice.  For instance, running java-0.10 on
my machine takes 30mins.  This is harming productivity.

Current profiles:

default.testprofile  - tests 0-8 using in-VM, broker/client share JVM,
Memory Message Store
java.testprofile - tests 0-9-1, using tcp, separate JVMs, Memory Message
java-derby.testprofile - tests 0-9-1, using tcp, separate JVMs, Derby
Message Store

java.0.10.testprofile   - tests 0-10, using tcp, separate JVMs,, Memory
Message Store
java-derby.0.10.testprofile -- tests 0-10, using tcp, separate JVMs, Derby
Message Store

My proposal:

Four profiles intended for regular developer use.  These profiles will
exploit the feature for client/broker to share the same VM.  This saves the
overhead of each testcase spawning a new broker as a separate process, and
brings the length of time to run the profile down considerably, assisting
developer productivity.

(mms=memory message store, dby = Apache Derby)



Running client/broker in separate JVMs remains valuable, but is probably not
something most developers will want to do most of the time (because of the
time overhead).    The intention would be we'd schedule these to run on CI
(using Jenkin's matrix feature) and let Jenkins do the heavy lifting.



The idea of the default testprofile would disappear and it would become an
error to run -Dprofile=default.   If the developer omits -Dprofile from the
Ant command line, the system will run java-mms.0-10, which I think will be
useful fallback to most developers.

I think we also need a "Java Test Howto" page on the website, explaining the
purposes behind the profiles, the differences between system and non-system
tests and giving advice on appropriate use of both.

Any thoughts?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message