<p dir="ltr">It seems like this is precisely what the functional test setup was designed to handle. Is there a reason you don't want to run them as functional tests instead of unit tests?</p>
<p dir="ltr">As functional tests, nobody would need new prereqs just to make it through unit tests and anyone that wants to do the full tests can install them and run 'tox functional'. </p>
<p dir="ltr">This is how neutron is starting to test the behavior of OVS and it seems to work well. </p>
<div class="gmail_quote">On Aug 1, 2014 6:01 AM, "Ken Giusti" <<a href="mailto:kgiusti@gmail.com">kgiusti@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>