Hi Malintha, I'm sorry your clarification is not that clear, could you please elaborate the drawbacks?
May be you could compare the effort of updating a test configuration file (a config file update) in a test suite against the effort of updating a configuration file generation logic (a code change) which you may have to introduce in the test suite in your sample scenario. Thanks On Thu, Mar 27, 2014 at 12:25 AM, Malintha Adikari <[email protected]>wrote: > Hi Imesh, > > I see some drawbacks in storing configuration files (JASON payloads) in > test suits rather than prepare them at runtime. In a case we want to change > those configuration details , we have to go each and every configuration > file (JSON) and change the content. TAF facilitate (automation.xml file > [1]) store and retrieve test configuration details for users. For Stratos > users (test writers) can decide an appropriate structure to store those all > configurations and later obtain them in runtime. > > [1] https://docs.wso2.org/display/TA430/Automation.xml+File > > Regards, > Malintha Adikari > > > On Thu, Mar 27, 2014 at 2:00 AM, Imesh Gunaratne <[email protected]> wrote: > >> 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 >> >> > > > -- > *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 > -- *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
