cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Santhosh Kumar Edukulla (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-6384) [Marvin]: Base.py and Service class changes
Date Wed, 16 Apr 2014 09:30:15 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-6384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Santhosh Kumar Edukulla updated CLOUDSTACK-6384:
------------------------------------------------

    Description: 
1. Currently, the way base.py has been used especially with related to passing and using services
dictiionary is far confusing. 
2. Any change we do to services dictionary and its structure effects base.py functionality,
ideally it should abstract the base.py interfaces from internal data structures usage. 
3. We are not sure as which elements in services dictionary are mandatory and which are not.
This we can make sure to mention and use base.py classes to have these parameters defined.
4. Writing test code in an easier fashion. We can make the base.py classes accept default
keyword values defined from config\test_data, or services. Now, test suites can start using
them with out worrying much about the services\test_data while creating, listing, using etc.

EX: We will just say 
obj = Network()// Network class constructor will have keyword arguments defined with default
values or filled in from test_data.
network_obj.create(),

rather as we are doing now currently.

EX: obj=Network(args)
network_obj.create(args_again)

Now, test writing need not worry much about services, then that should be good. 
5. This makes test writing cleaner and simpler. Lot places, we play around and shuffle with
services dictionary which is unwarranted. 

  was:
1. Currently, the way base.py has been used especially with related to passing and using services
dictiionary is far confusing. 
2. Any change we do to services dictionary and its structure effects base.py functionality,
ideally it should abstract the base.py interfaces from internal data structures usage. 
3. We are not sure as which elements in services dictionary are mandatory and which are not.
This we can make sure to mention and use base.py classes to have these parameters defined.
4. Writing test code in an easier fashion. We can make the base.py classes accept default
keyword values defined from test_data, or services so that tests can start using them in tests
with out worrying much with creating, listing, using etc. EX: We will just say Network_obj.create(),
rather passing complete argument list at times, if we can define keyword and mandatory arguments
defined with initial default values to these apis, then that should be good. 
5. This makes test writing cleaner and simpler. Lot places, we play around and shuffle with
services dictionary which is unwarranted. 


> [Marvin]: Base.py and Service class changes
> -------------------------------------------
>
>                 Key: CLOUDSTACK-6384
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6384
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: marvin
>            Reporter: Santhosh Kumar Edukulla
>
> 1. Currently, the way base.py has been used especially with related to passing and using
services dictiionary is far confusing. 
> 2. Any change we do to services dictionary and its structure effects base.py functionality,
ideally it should abstract the base.py interfaces from internal data structures usage. 
> 3. We are not sure as which elements in services dictionary are mandatory and which are
not. This we can make sure to mention and use base.py classes to have these parameters defined.
> 4. Writing test code in an easier fashion. We can make the base.py classes accept default
keyword values defined from config\test_data, or services. Now, test suites can start using
them with out worrying much about the services\test_data while creating, listing, using etc.

> EX: We will just say 
> obj = Network()// Network class constructor will have keyword arguments defined with
default values or filled in from test_data.
> network_obj.create(),
> rather as we are doing now currently.
> EX: obj=Network(args)
> network_obj.create(args_again)
> Now, test writing need not worry much about services, then that should be good. 
> 5. This makes test writing cleaner and simpler. Lot places, we play around and shuffle
with services dictionary which is unwarranted. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message