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

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

Reply via email to