[openstack-qa] Refactoring Tempest service clients

Daryl Walleck daryl.walleck at RACKSPACE.COM
Mon Jul 1 15:07:10 UTC 2013


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



More information about the openstack-qa mailing list