qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: In memory/embedded Java client testing
Date Mon, 08 Dec 2014 15:00:21 GMT
On Fri, 2014-12-05 at 11:17 +0000, Rob Godfrey wrote:
> On 4 December 2014 at 01:13, Nathan Kunkee <nkunkee@genome.wustl.edu> wrote:
> 
> > Hi all,
> >
> > I have a project that successfully passes messages between Glassfish 4,
> > Qpid 0.30 JCA adapter (see also the issues I logged), and RabbitMQ 3.3.4. I
> > am now looking to add some integration tests in Java for the entire message
> > flow, so through producers and consumers. As the InVM version of the broker
> > was retired, the only guide I've found for this is the following
> > stackoverflow post:
> >
> > http://stackoverflow.com/questions/2176043/example-of-
> > standalone-apache-qpid-amqp-junit-test
> >
> >
> Sadly, that's probably about the best way to do it at the moment - It
> shouldn't be a *huge* piece of work for us to recreate something like the
> old InVM transport, but it's just not something we've prioritized so far.
> I'll take a look at it over the weekend to see how big a piece of work it
> might be.  Similarly it would be nice if we provided a way to set up
> configuration in memory for an embedded broker for testing purposes so you
> don't have to write out config files... I'll take a look at that as well.

I  have become wary with the years of using special transports for
testing. Ever heard the expression "test what you fly, fly what  you
test?" If there's a requirement for inVM or in-memory transports in
production that is a different story, but if it's just about testing IMO
it's better to put the effort into building a more realistic harness
that tests the real transport than into building a fake transport that
is easier to test.

> > Is there any other or easier way to incorporate the Qpid Java broker into
> > testing? Does anyone have any suggestions for how to inject mock objects
> > related to Qpid into my testing?

Mock objects and unit tests are a good thing up to a certain point, but
beyond that point is better to test the *real* objects working together.
If that makes your tests too slow, it tells you something important
about the performance of the real objects! If you want to incorporate a
java broker in your tests - why not just run a java broker?

Example of what  I'm on about: see the ha_tests in the qpid C++ tree.
Basically they co-ordinate real brokers in real clusters (with some
fakery around picking port numbers) so they really test clustered
behavior. The only thing they *don't* test is the integration with
rgmanager or other cluster resource managers - that's all mocked out.
Guess where most of my problems were when this hit real QA? That's
right, in the integration with rgmanager.


> > I appreciate any ideas you have! Thank you,

Just ranting, feel free to ignore if I'm way off the track.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message