Open Stack

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?

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'.

This is how neutron is starting to test the behavior of OVS and it seems to
work well.
On Aug 1, 2014 6:01 AM, "Ken Giusti" <kgiusti at gmail.com> wrote:

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