Open Stack

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.

But - as always- only my $0.02.