<div dir="ltr"><br clear="all">On Wed, 30 Jul 2014 15:04:41 -0700, Matt Riedemann wrote:<br>>On 7/30/2014 11:59 AM, Ken Giusti wrote:<br>>> On Wed, 30 Jul 2014 14:25:46 +0100, Daniel P. Berrange wrote:<br>>>> On Wed, Jul 30, 2014 at 08:54:01AM -0400, Ken Giusti wrote:<br>
>>>> Greetings,<br><snip><br>>> At this point, there are no integration tests that exercise the<br>>> driver.  However, the new unit tests include a test 'broker', which<br>>> allow the unit tests to fully exercise the new driver, right down to<br>
>> the network.  That's a bonus of AMQP 1.0 - it can support peer-2-peer<br>>> messaging.<br>>><br>>> So its the new unit tests that have the 'hard' requirement of the<br>>> proton libraries.    And mocking-out the proton libraries really<br>
>> doesn't allow us to do any meaningful tests of the driver.<br>>><br><snip><br>><br>>If your unit tests are dependent on a specific dependent library aren't<br>>they no longer unit tests but integration tests anyway?<br>
><br><br>Good point - yes, they are certainly more than just unit tests.  I'd<br>consider them more "functional" tests than integration tests, tho:<br>they only test from the new driver API down to the wire (and back up<br>
again via the fake loopback broker).  For integration testing, I'd<br>want to put a real broker in there, and run real subprojects over<br>oslo.messaging using the new driver (neutron, etc).<br><br>I'd really like to avoid the classic unit test approach of mocking out<br>
the underlying messaging client api if possible.  Even though that<br>would avoid the dependency, I think it could result in the same issues<br>we've had with the existing impl_qpid tests passing in mock, but<br>failing when run against qpidd.<br>
<br>>Just wondering, not trying to put up road-blocks because I'd like to see<br>>how this code performs but haven't had time yet to play with it.<br>><br><br>np, a good question, thanks!  When you do get a chance to kick the tires,<br>
feel free to ping me with any questions/issues you have.  Thanks!<br><br>>--<br>><br>>Thanks,<br>><br>>Matt Riedemann<br><br></div>