openstack-qa-team team mailing list archive

[Daryl Walleck <daryl.walleck@xxxxxxxxxxxxx>]

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.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-qa-team-bounces+donald.ngo=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Daryl Walleck
> Sent: Saturday, October 15, 2011 11:24 AM
> To: openstack-qa-team@xxxxxxxxxxxxxxxxxxx
> 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.com@xxxxxxxxxxxxxxxxxxx [openstack-qa-team-bounces+daryl.walleck=rackspace.com@xxxxxxxxxxxxxxxxxxx] on behalf of David Kranz [david.kranz@xxxxxxxxxx]
> Sent: Friday, October 14, 2011 10:11 AM
> To: openstack-qa-team@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> 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.