To avoid test client duplication, a new git repository will be introduced with common set of clients and default plugable test framework extensions.
Thanks, Krishantha. On Fri, Mar 7, 2014 at 2:28 PM, Krishantha Samaraweera <[email protected]>wrote: > As per the offline discussion had on $subject, a decision was made to > distribute service stub clients among products. The admin service clients > of test framework is implemented to support for test automation, so putting > those clients under service stubs will not make much sense because there > are not generic clients. So anybody who needs to use admin services API > should implement their own clients in integration test scope. > > This will introduce client duplication among products integration tests. > However this duplication is necessary if products are going to depend on > older versions of the components. I see many problems with migrating test > framework to git repo based model. Because test framework extensions, which > facilitate server start-up and user population depends on service-stub > dependencies. Also certain common tests which can be extended by each > product will have to duplicated again. We need to duplicate these > extensions and common tests among products if products are not going to use > latest versions of components in each release. > > Will be a policy which enforce to use latest version of product > dependencies ? or can product teams use older version of the > dependencies/components as they wish? > > Thanks, > Krishantha. > > > On Mon, Mar 3, 2014 at 10:04 PM, Krishantha Samaraweera < > [email protected]> wrote: > >> On Mon, Mar 3, 2014 at 9:55 PM, Sagara Gunathunga <[email protected]>wrote: >> >>> >>> >>> >>> On Mon, Mar 3, 2014 at 6:10 PM, Krishantha Samaraweera < >>> [email protected]> wrote: >>> >>>> Hi all, >>>> >>>> I would like to propose $subject. The test automation framework heavily >>>> depends on admin service clients which use service-stubs to invoke backend >>>> admin services. This approach will by-pass the management UI and call the >>>> backend web services directly. Maintaining set of Admin service clients >>>> inside test automation framework has it's own pros and cons. >>>> >>>> The main problems is maintenance overhead. There were incidents that >>>> service API has changed and no one build the branch up to test framework >>>> level before the commit. So this introduced compilation failures in test >>>> framework API. With our new git based repository model, eliminating this >>>> kind of mistakes are required to scale fast. Moving these clients to >>>> service-stub level guarantee to detect any compilation failures at >>>> repository level. Since the framework support for platform level test >>>> automation, all most all service-stubs were taken as dependencies to test >>>> framework API. This will introduce many drawbacks when it comes to single >>>> product release. >>>> >>>> Moving admin services clients will improve test-ability and provide >>>> user friendly way for product users to consume admin services. Also this >>>> will eliminate necessity of releasing all service stubs at the time of >>>> automation framework release (in initial phase) >>>> >>>> Please let me know your suggestions? >>>> >>> >>> +1 >>> >>> I assume after moving these clients in to underline stub modules >>> particular team is responsible for maintenance. IMHO to make it more >>> practical we should add process so that when introducing a new stub there >>> should be a new service client as well WDYT ? >>> >>> During the initial stage it would be better automation team can >>> distribute existing service clients into among platform projects to keep >>> consistency. >>> >> >> Automation team can own initial distribution of Service clients among >> service-stub modules. >> >> Thanks, >> Krishantha. >> >> >>> Thanks ! >>> >>>> >>>> Thanks, >>>> Krishantha. >>>> >>>> -- >>>> Krishantha Samaraweera >>>> Senior Technical Lead - Test Automation >>>> Mobile: +94 77 7759918 >>>> WSO2, Inc.; http://wso2.com/ >>>> lean . enterprise . middlewear. >>>> >>> >>> >>> >>> -- >>> Sagara Gunathunga >>> >>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>> V.P Apache Web Services; http://ws.apache.org/ >>> Linkedin; http://www.linkedin.com/in/ssagara >>> Blog ; http://ssagara.blogspot.com >>> >>> >> >> >> -- >> Krishantha Samaraweera >> Senior Technical Lead - Test Automation >> Mobile: +94 77 7759918 >> WSO2, Inc.; http://wso2.com/ >> lean . enterprise . middlewear. >> > > > > -- > Krishantha Samaraweera > Senior Technical Lead - Test Automation > Mobile: +94 77 7759918 > WSO2, Inc.; http://wso2.com/ > lean . enterprise . middlewear. > -- Krishantha Samaraweera Senior Technical Lead - Test Automation Mobile: +94 77 7759918 WSO2, Inc.; http://wso2.com/ lean . enterprise . middlewear.
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
