Open Stack

>>>
>>>What you are describing (partly) in your blueprint are fixture objects. 
>>>I fully support this approach, and I even put a proof of concept 
>>>together back in January that handled user and tenant management using 
>>>fixtures: 
>>>
>>>https://github.com/jaypipes/tempest/blob/api/tempest/fixtures/identity.py 
>>>
>>>Note that it uses the fixtures library [1] from Robert Collins (lifeless 
>>>on IRC) and the code uses the python-keystoneclient library directly 
>>>instead of the Tempest clients. 
>>>
>>>The base test case in the proof-of-concept code inherits from 
>>>testtools.TestCase and fixtures.TestWithFixtures. This adds to the base 
>>>test class the addFixture() method, which ensures that any fixtures are 
>>>automatically cleaned up when tearDown is called. 
>>>
>>>Perhaps you might take a look at the code and see if it would be useful. 
>>>
>>>Best, 
>>>-jay 
>>>
>>>[1] https://pypi.python.org/pypi/fixtures 
>>>[2] 
>>>https://github.com/jaypipes/tempest/blob/api/tempest/tests/api/base.py#L44 

Personally, I am unfamiliar with "fixtures", but the concept of what you did is exactly what I had in mind (except for the name of the identity class that I believe should be changed to "KeystoneFixture" as this identity component that you implement is Keystone specific.)
>From briefly reading about fixtures, I don't really see how it is different from a simple OOP concept, but I will comment more on the matter once I read it fully.

>>>
>>>
>>>I don't really think we need a Manager class at all. It serves no 
>>>purpose, IMO.

Agreed, the only reason I mentioned it was to try and stay with the current design of things and not just remove random stuff ;)

> In the "services" folder.
> Why do we need two clients for JSON/XML?

>>>Because both code paths need testing?

We can avoid it by simply creating a "Request" object that is comprised out of:
method / request line
headers
body (entity)

This way, the object is "dumb" and doesn't care what kind of implementation we choose for the communication.
If you want, you can take it even further and inherit/composite it to RequestXML, RequestJSON that already have the proper headers, though I personally, I believe it will be a redundent step.
By doing this, the client format is independent and can focus only on what it suppose to do, that is sending the request and getting the response. (again, we can further divide the responsibility, but that is a topic of it's own :) )

>>>I don't believe we need a Manager class at all. We should use the 
>>>fixtures.Fixture class as our basic unit of test-needed resources and 
>>>use fixtures.TestWithFixtures to handle much of the plumbing.

Agreed (as stated above :) ), I see no reason why we need the Manager class at all.

Best,
-jay
<<<

Regards,
Tal