In memory/embedded Java client testing

[Nathan Kunkee <nk...@genome.wustl.edu>]

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

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?

I appreciate any ideas you have! Thank you,
Nathan

____
This email message is a private communication. The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential, privileged, and/or proprietary material. Any review, duplication, retransmission, distribution, or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is unauthorized by the sender and is prohibited. If you have received this message in error, please contact the sender immediately by return email and delete the original message from all computer systems. Thank you.

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

Re: In memory/embedded Java client testing

[Alan Conway <ac...@redhat.com>]

On Fri, 2014-12-05 at 11:17 +0000, Rob Godfrey wrote:
> On 4 December 2014 at 01:13, Nathan Kunkee <nk...@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

Re: In memory/embedded Java client testing

[Rob Godfrey <ro...@gmail.com>]

On 4 December 2014 at 01:13, Nathan Kunkee <nk...@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.


> 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?
>
> I appreciate any ideas you have! Thank you,
> Nathan
>

Sorry I can't be more help right now.

-- Rob


>
> ____
> This email message is a private communication. The information
> transmitted, including attachments, is intended only for the person or
> entity to which it is addressed and may contain confidential, privileged,
> and/or proprietary material. Any review, duplication, retransmission,
> distribution, or other use of, or taking of any action in reliance upon,
> this information by persons or entities other than the intended recipient
> is unauthorized by the sender and is prohibited. If you have received this
> message in error, please contact the sender immediately by return email and
> delete the original message from all computer systems. Thank you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>