I think I see what you're getting at David. However, I don't see how using a layer of abstraction between the test and the functionality that makes the request isn't still directly testing the APIs. From a maintainability standpoint, having each test maintain it's own authentication and request structure will end up being very costly. Maybe calling what I'm advocating a wrapper isn't exactly the right term. To refer to UI testing, my reasoning falls back to design patterns like the Page Object pattern: reusability of code, scalability, and maintainability.
Daryl On Oct 17, 2011, at 12:32 AM, Ngo, Donald (HP Cloud Services : QA) wrote: > I was looking at the Kong integrated tests and they look pretty good. They > are testing the underlying REST apis. I think this is the ultimate test since > the Openstack python libraries and any other wrappers ultimately make http > request to these REST apis. In other words if the REST apis are not > functionally working they will for sure fail when we use wrappers to call > them. > > Thanks, > > Donald > > -----Original Message----- > From: openstack-qa-team-bounces+donald.ngo=hp....@lists.launchpad.net > [mailto:openstack-qa-team-bounces+donald.ngo=hp....@lists.launchpad.net] On > Behalf Of Daryl Walleck > Sent: Saturday, October 15, 2011 11:24 AM > To: openstack-qa-team@lists.launchpad.net > Subject: Re: [Openstack-qa-team] Python wrappers for OpenStack APIs > > I think the final solution will come from the openstack-integration-tests > project. I think the novaclient project would be a reasonable choice if > you're looking for a solution immediately. I agree that a good long term > solution for httplib type tests would be to have a common request driver so > that we can keep the actual requests out of the test code. There's an example > of an implementation like this in my GitHub > (https://github.com/dwalleck/zodiac), which is a test design pattern I've > used in past with great success. I'd be very interested in hearing others > opinions on this as well, as I think the decisions we make now will have long > term effects on our test infrastructure going forward. > > Daryl > > ________________________________________ > From: > openstack-qa-team-bounces+daryl.walleck=rackspace....@lists.launchpad.net > [openstack-qa-team-bounces+daryl.walleck=rackspace....@lists.launchpad.net] > on behalf of David Kranz [david.kr...@qrclab.com] > Sent: Friday, October 14, 2011 10:11 AM > To: openstack-qa-team@lists.launchpad.net > Subject: [Openstack-qa-team] Python wrappers for OpenStack APIs > > I have been implementing some functional stress tests for nova. It > seems that there are various pieces of Python code that have been > written to call the HTTP apis including novaclient as well as code that > is part of various test suites. There are also ueca-tools. It seems like > it would be useful to have a "standard" set of test driver code going > forward. Does any one have any comments about this, or a suggestion > about which client API code would be best to use? > > -David > > > > -- > Mailing list: https://launchpad.net/~openstack-qa-team > Post to : openstack-qa-team@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack-qa-team > More help : https://help.launchpad.net/ListHelp > This email may include confidential information. If you received it in error, > please delete it. > > > -- > Mailing list: https://launchpad.net/~openstack-qa-team > Post to : openstack-qa-team@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack-qa-team > More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
