Jump to: navigation, search


As part of the current on going Tempest redesign, I would like to propose the encapsulation of data into objects as a base for future Factory implementation.

For example: (I'll use the Identity component "Keystone" as an example) We should create an object Called: "KeystoneUser" which will hold all the relevant keystone user information (like username, password, token (if exist), tenant, etc) This approach gives you the power to be modular in your design, it adds readability, can be used to write more general purpose methods in the future (see example below) and avoid conflicts if something has changed. (like if the Devs decide to add / remove a parameter like "tenant" for example)

So code such as:

   self.client.create_user(self.alt_user, self.alt_password,

Can be rewritten into:


Where "user" represents an Object of type KeystoneUser. (In this case)

Note that this approach gives us the power to change the "create_user" method in the future to allow the use of different Identity component, thus reuse our code. (and object)

This is only an example taken from the current Identity implementation, but it can easily be generalized into other objects as well.

From here we can easily move (in the future) to a more general "User" type with basic username/password, so if someone would like to add/replace the Identity component to something else, all that he/she will need to do is inherit/composite the User class while the test itself will stay the same. (but this is a whole new blueprint by itself)

I believe that in general, we should try and make Tempest as modular as possible and encapsulating / separating responsibilities into objects can be a good first step.

--Tkammer (talk) 14:10, 5 June 2013 (UTC)