On Fri, 2014-12-05 at 11:17 +0000, Rob Godfrey wrote: > On 4 December 2014 at 01:13, Nathan Kunkee <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
