On Mon, Nov 28, 2016 at 11:39 AM, Kim van der Riet <[email protected]> wrote: > On 11/28/2016 11:14 AM, Matt Broadstone wrote: >> >> Hi Kim, >> >> I'm the maintainer of a node.js AMQP 1.0 client >> (https://github.com/noodlefrenzy/node-amqp10) and am highly interested >> in finding a way to incorporate our client into your tests if at all >> possible. We currently run a limited set of integration tests against >> the latest released qpidd in TravisCI, however I gather this would be >> far more comprehensive. >> >> To that end, a few questions: >> >> * is it out of scope to include an external library in these tests? >> / would you be interested in such work >> * it seems like this is simply a matter of providing a shim similar >> to the one provided for rhea, is there anything else I might be >> missing there? >> * I'm sure that we have gaps in our implementation in terms of full >> coverage, if the answer to the first question is (no, then yes), what >> is your timeline for a release of the test suite? >> >> Regards, >> Matt Broadstone > > > It is absolutely possible to add clients to the test suite, and I would > certainly encourage it! To answer your questions: > > * I don't see any difficulty including an external client library to the > tests (and indeed, Rhea is technically an external lib too). I think if we > can add the right logic into the installation portion of the tests, then it > would not be an issue if someone else does not have the external libs > present (they would simply not run). I would like to have as many of the > clients as the installer can find run by default. > > * Yes, the idea would be to write a shim which can interpret the > command-line parameters sent to it and send those as AMQP messages. I have > not had a chance to look at your project yet, but I would asume that the > Rhea shims would make a good pattern for you to work from. The tests do > incorporate a way to initially skip some tests if you are not > feature-complete or there is a known bug which would cause the test to fail. > > * I hope to provide a snapshot release soon (in the next few weeks once I > have received some initial feedback from the community), followed by a full > official release of v 1.0 as the project progresses (ta-da!) > > I hope that helps, please keep asking if you have further questions. > > Kim > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
Kim, I had tried to quickly build and run the tests before my vacation, but ran into problems at the time and gave up. I'm going through the process again today and still encountering a number of issues: * it seems proton''s `symbol.hpp` uses `std::string` without actually including it - so `JmsTestBase.cpp` fails to build without `<string>` being included. * when linking the `Receiver` it cannot find `-lqpid-proton-cpp` (I have proton 0.14.0 installed on ubuntu here) * I then tried just commenting out the CPP and Java tests (since I'm only interested in integrating node-amqp10 here), and `make install` resulted in the following: ``` chmod: cannot access ‘amqp_large_content_test.py’: No such file or directory chmod: cannot access ‘amqp_types_test.py’: No such file or directory chmod: cannot access ‘jms_hdrs_props_test.py’: No such file or directory chmod: cannot access ‘jms_messages_test.py’: No such file or directory ``` The tests seem to be somewhat dependent on a particular environment. I wonder if it would be possible to make the whole framework a little more modular? Also just a quick architectural question: why are the tests being installed globally as python modules? Hope I'm helping here. Cheers, Matt --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
