Open Stack

The point of things in the api/ directory is to test the API, which is
why we have those clients, and those tests. It's actually a core
purpose of the test suite. It's also a core purpose to be explicit
about return codes, so those have to be exposed to the tests. That's
part of the thing we are testing, for the API portion of the test
tree. It's not a side effect, it's actually the whole purpose of the
tests. It's double entry book keeping for our API, yes its effort, but
you can't have a stable API unless you do it.

Anyway, we've been around in circles about this a few times now in the
last 2 months. Specific cleanups are welcomed, and will be reviewed.
So please be specific and not general in this space. Gutting API
testing is not welcomed or appropriate.

Scenario/ is designed for tests that you want to use the official
clients. It's totally ok to add more complicated tests over there
which aren't API tests.

Lastly, I'm actually out on vacation for the week, so expect
substantial, if not complete ignoring of threads here until I get
back.

On Mon, Jul 1, 2013 at 11:07 AM, Daryl Walleck
<daryl.walleck at rackspace.com> wrote:
> There are certainly ways to accomplish this. The way that I've found to be the most easy to maintain is to implement serializers/deserializers rather that implement two separate clients. It greatly simplifies the client logic and makes a clean break between client and serialization logic. You can see an example of that here:
>
> https://github.com/stackforge/cloudcafe/blob/master/cloudcafe/compute/servers_api/models/requests.py
>
> Daryl
> ________________________________________
> From: Martina Kollarova [mkollaro at redhat.com]
> Sent: Monday, July 01, 2013 6:19 AM
> To: All Things QA.
> Subject: [openstack-qa] Refactoring Tempest service clients
>
> 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.
>
>
> Thoughts?
>
> Martina Kollarova
> --
> irc: mkollaro
>
> _______________________________________________
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
>
> _______________________________________________
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa



-- 
Sean Dague
http://dague.net