qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: Ideas to rationalise the Java test profiles.
Date Mon, 04 Jul 2011 14:39:01 GMT
Just to add to it, any changes to the Java client should also be
tested with the cpp test profile.
Any changes to the client failover mechanism should also be tested
with the cpp.cluster profile.

I know it's a pain to run all these profiles, especially considering
each run takes about 30-40 mins.
But atm there is no better alternative. I think long term we need to
evaluate our testing strategy to see if we can come up with something
more efficient.



On Mon, Jul 4, 2011 at 7:11 AM, Robert Godfrey <rob.j.godfrey@gmail.com> wrote:
> On 4 July 2011 12:44, Keith Wall <keith.wall@gmail.com> wrote:
>> 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
>> Store
>> 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)
>> java-mms.0-10
>> java-dby.0-10
>> java-mms.0-9-1
>> java-dby.0-9-1
>> 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.
>> java-mms-spawn.0-10
>> java-dby-spawn.0-10
>> java-mms-spawn.0-9-1
>> java-dby-spawn.0-9-1
>> 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?
>> Keith.
> All sounds exceedingly sensible to me.
> -- Rob

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message