Re: Qpid Interop Test Suite

[Matt Broadstone <mb...@gmail.com>]

On Mon, Nov 28, 2016 at 11:39 AM, Kim van der Riet
<ki...@redhat.com> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Qpid Interop Test Suite

[Kim van der Riet <ki...@redhat.com>]

On 12/11/2016 10:37 AM, Matt Broadstone wrote:
> 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:
Hi Matt,

I am sorry you are having install issues, but it does not surprise me at 
all. The install part of this has been rather quickly thrown together, 
and still needs some work.  I am rather new at the install side of 
things, but I am learning ...  Your experience with the install and 
feedback is very valuable to me. Thank you.

>
>  * it seems proton''s `symbol.hpp` uses `std::string` without actually
> including it - so `JmsTestBase.cpp` fails to build without `<string>`
> being included.
Hmmm... That was fixed some time ago, perhaps you don't have the latest 
Proton? See PROTON-1313 "c++: missing #include<string> in some headers", 
and was checked in on Oct. 6, 2016.

>
>  * when linking the `Receiver` it cannot find `-lqpid-proton-cpp` (I
> have proton 0.14.0 installed on ubuntu here)
The install is reasonably immature at the moment, so it is possible that 
it is not being correctly located.  I build proton from source, then 
perform a local install. Do you know where proton installs to in Ubuntu?
>
>  * 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 \u2018amqp_large_content_test.py\u2019: No such file or directory
> chmod: cannot access \u2018amqp_types_test.py\u2019: No such file or directory
> chmod: cannot access \u2018jms_hdrs_props_test.py\u2019: No such file or directory
> chmod: cannot access \u2018jms_messages_test.py\u2019: No such file or directory
> ```
>
It seems that the entire install did not work somehow, as these are the 
main tests in the global python location.

> 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?
I am working on that. I think I need to test on Ubuntu. There are 
several install issues on JIRA at the moment.
>
> Also just a quick architectural question: why are the tests being
> installed globally as python modules?
That depends on the value of CMAKE_INSTALL_PREFIX.  By default, it does 
install to a global location.  The shims also install into that path, 
and I need to change that, as they are not (all) python executables. I 
have a JIRA open for this issue.

Thanks so much for having a go at this. Your feedback is valuable!

Kim

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