Hi Malintha,

In Stratos we have considerable amount of configurations to be done. I'm
not sure it would be feasible to store all of them in a test configuration
file and generate each configuration file in runtime.

I think the best option would be to store sample configuration files within
the test suite and use them in runtime. We have already done this in
existing tests suites.

Thanks


On Wed, Mar 26, 2014 at 7:30 AM, Dharshana Warusavitharana <
[email protected]> wrote:

> Hi Malintha,
>
> The practice is if someone needs a different set of configurations in
> different test suites. Users can alter or add any custom configuration
> nodes to the configuration. Its acceptable as far as custom
> configurations does not alter the critical configurations defined by the
> original xsd.
>
> To retrieve the configurations, users can implement custom  configuration
> mapper classes inside the test suite, depending on his requirement.
>
> So we do not want to alter any existing behaviors, Any custom
> configurations are accessible through xpath as all other existing
> configurations.
>
> Thank You,
> Dharshana.
>
>
> On Wed, Mar 26, 2014 at 4:46 PM, Malintha Adikari <[email protected]>wrote:
>
>> Hi,
>>
>> I am working on evaluating WSO2 test Automation Framework for automating
>> Apache Stratos tests. In WTAF we use central configuration file
>> (automation.xml) to store all configurations related to tests. So in Apache
>> Stratos case we have to use automation.xml to store all configurations
>> related to test. Currently we have designed that configuration file
>> considering our common requirements. While examining Stratos configuration
>> details I could observe that automation.xml cannot be used as it is to
>> store those configurations. We already allow users to store custom
>> properties in automation.xml.
>>
>> <property name="region">myRegion</property>
>> <property name="zone">myZone</property>
>>
>> But the configuration I found in Apache Stratos cannot be formatted into
>> above simple structure
>>
>> Ex: Consider following configuration details for partition deployment (
>> This cannot be simply mapped into above property nodes - There are 2
>> partitions that has same structure )
>>
>> Partition 01:
>>
>>   porvider: aaa
>>   region:bbb
>>   zone:ccc
>>
>> Partition 02
>>
>>  provider:aab
>>  region:bbc
>>  zone:ccd
>>
>> IMO we have to facilitate users to define custom structures in
>> automation.xml an allow them to obtain configuration details from those
>> custom structures.I propose to change schema of the automation.xml file in
>> order to allow users to put their desired configurations in their own
>> structure in a separate node. And then it is their responsibility to obtain
>> those configuration details using the API already provided by WTAF.
>>
>> Regards,
>> Malintha Adikari
>>
>> --
>> *Malintha Adikari*
>>  Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> Mobile: +94 71 2312958
>> Blog:    http://malinthas.blogspot.com
>> Page:   http://about.me/malintha
>>
>
>
>
> --
>
> Dharshana Warusavitharana
> Senior Software Engineer , Test Automation
> WSO2 Inc. http://wso2.com
> email : [email protected] <[email protected]>
> Tel  : +94 11 214 5345
> Fax :+94 11 2145300
> cell : +94772202595
> blog : http://dharshanaw.blogspot.com
>
> lean . enterprise . middleware
>
> _______________________________________________
> Dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Imesh Gunaratne*
Technical Lead
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: http://imesh.gunaratne.org
Lean . Enterprise . Middleware
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to