Open Stack

On Jul 1, 2013, at 10:15 AM, Monty Taylor <mordred at inaugust.com> wrote:

> On 07/01/2013 04:19 AM, Martina Kollarova wrote:
>> Problem: There is a lot of redundancy in the code around the XML and
>> JSON API formats and API versions. The client classes are very low-level
>> and hard to use.
>> 
>> There should be a single general class for each service that would
>> contain as much common code as possible. Then there would be derived
>> classes for JSON, XML and different API versions that would only
>> overwrite the differences. Ideally, there could be derived class that
>> would also handle the CLI.
>> How to do this with the least amount of redundancy?
>> 
>> This way, the tests would be written only once and most of them run for
>> each API version/format. Then there would be tests for only a specific
>> API version, when new API features would be tested.
>> 
>> The general classes should also be more high-level. They could
>> themselves manage the resources that were created with them and be able
>> to clean them up. The classes would check the response codes themselves
>> and throw exceptions, instead of having
>> "assertEqual(resp['status'], '200')"
>> everywhere in the test code.
> 
> I think that if you do this, you will wind up implementing a parallel
> set of client libraries.
> 
> I'm going to take this moment to advocate for just using the client
> libraries in tempest instead of direct HTTP, btw. 2 reasons - one - what
> Martina brings up - it's hard to write things with the direct HTTP. Two
> - we have integration testing for real at this point, whereas we did not
> have it when tempest was first written/designed. So the fact that the
> client libs are part of the gate should mitigate that.

+1.  

As much as I can accept that testing involves a certain amount of duplicate effort, I see little value in implementing a second set of client libraries (poorly).


m.

> 
> But - as always- only my $0.02.
> 
> _______________________________________________
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa