@dharshana can you confirm rest easy version we should use in Apim 1.10x. It seems http client version conflict happen in automation tests due to obove import.
Thanks sanjeewa. sent from my phone On Nov 20, 2015 2:37 PM, "Dharshana Warusavitharana" <[email protected]> wrote: > Hi Sanjeewa, > > This is ok to add these dependencies but for jax-rs please refer the > jax-rs wso2 version that used in the product. Else there will be confilcts. > > Thank you, > Dharshana. > > On Fri, Nov 20, 2015 at 2:29 PM, Sanjeewa Malalgoda <[email protected]> > wrote: > >> Hi Team, >> While implementing test case as per sample provided by dharshanaW i >> wanted add following dependencies to test back end pom. >> >> <dependency> >> <groupId>javax.ws.rs</groupId> >> <artifactId>javax.ws.rs-api</artifactId> >> <version>2.0.1</version> >> </dependency> >> <dependency> >> <groupId>org.jboss.resteasy</groupId> >> <artifactId>resteasy-client</artifactId> >> <version>3.0.2.Final</version> >> >> Is it ok if added these dependencies to back end tests module? >> We have implemented generic data driven test utility class and we may >> move it to automation core as its common requirement. >> Its main methods input parameters as follows. >> >> testRestAPI(String url, String requestPayLoad, Map<String,String> header, >> Map<String, String> queryParams, >> String responsePayLoad) >> >> Thanks, >> sanjeewa. >> >> >> >> On Wed, Nov 18, 2015 at 4:58 PM, Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> As per discussion with automation test team our plan is to implement >>> data driven test cases for this. >>> With that we will be able to define request data and expected response >>> data. >>> The utility class we are going to implement will take request data and >>> then validate response with provided response. >>> If the API got changed in future we do not need to change test. >>> We can simply change the data set as per new API. >>> This approach will help us to implement test easily and manage them. >>> >>> Please let us know your thought on this. >>> >>> Thanks, >>> sanjeewa. >>> >>> >>> On Tue, Nov 3, 2015 at 5:49 PM, Krishantha Samaraweera < >>> [email protected]> wrote: >>> >>>> Hi Sanjeewa >>>> >>>> On Tue, Oct 20, 2015 at 2:47 PM, Sanjeewa Malalgoda <[email protected]> >>>> wrote: >>>> >>>>> QAA team shall we have discussion on this and come to conclusion? >>>>> Please let us know possible time slots. >>>>> >>>> >>>> +1 shall we meet this week. >>>> >>>> Thanks, >>>> Krishantha. >>>> >>>>> >>>>> Thanks, >>>>> sanjeewa. >>>>> >>>>> On Mon, Oct 19, 2015 at 12:44 PM, Sanjeewa Malalgoda < >>>>> [email protected]> wrote: >>>>> >>>>>> Here idea is easily manage the tests and web application. >>>>>> Since web application purely depend on swagger definition it will >>>>>> automatically generate beans, service skeletons etc. >>>>>> >>>>>> So in same way if we implement test cases we don't have to go and >>>>>> edit test case code after we adding new parameters or something like >>>>>> that. >>>>>> What we can simply do is change sample data set feed into test. >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Oct 19, 2015 at 12:34 PM, Joseph Fonseka <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Nuwan >>>>>>> >>>>>>> Thanks for pointing that out, in that case test can be version-ed so >>>>>>> auto generated tests for version 1.0.0 should work with API 1.0.1 ... >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>>> Regards >>>>>>> Jo >>>>>>> >>>>>>> On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Is it right to auto-generate the test client code? IMO one >>>>>>>> objective of this should be to make sure the REST APIs don't change >>>>>>>> across >>>>>>>> patch releases, etc. If we auto-generate the test stubs we would loose >>>>>>>> that >>>>>>>> advantage. >>>>>>>> >>>>>>> I don't get how we loose advantage here. >>>>>> If we don't want to change service API we don't have to edit swagger >>>>>> json and that is it. >>>>>> Then it will not change service API, neither test client or data set >>>>>> feed in to test. >>>>>> If we consider both integration and unit tests those will be released >>>>>> anyway with product and component release. >>>>>> So tests will be automatically version-ed with component/product >>>>>> version. >>>>>> >>>>>> Thanks, >>>>>> sanjeewa. >>>>>> >>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> NuwanD. >>>>>>>> >>>>>>>> On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Sanjeewa >>>>>>>>> >>>>>>>>> Saneth & I had an offline chat regarding this last week there are >>>>>>>>> few things we need to consider. >>>>>>>>> >>>>>>>>> 1. Generating integration test for the Jax-RS functionality ex . >>>>>>>>> If crud operations work, if it returns correct error messages. >>>>>>>>> - We can use swagger-codegen to do this. >>>>>>>>> - API Definition has all the details of the API >>>>>>>>> interface what missing are the data fixtures. >>>>>>>>> - There are few options with the fixtures which we can >>>>>>>>> auto generate since the schema of the model is there or we can use a >>>>>>>>> predefined set of json files. >>>>>>>>> >>>>>>>>> 2. How to get the existing integration test to utilize the new >>>>>>>>> API. >>>>>>>>> - We already have a lot of integration tests which uses >>>>>>>>> existing store & publisher APIs to add/remove resources. As Saneth >>>>>>>>> mention >>>>>>>>> they have written it in a layered architecture this replacing the >>>>>>>>> existing >>>>>>>>> API layer with Jax-rs existing test should work. >>>>>>>>> - We might have to look at this in the next phase when we >>>>>>>>> plan to deprecate the existing APIs. >>>>>>>>> >>>>>>>>> 3. How to make it easy to write test in the future with Jax-Rs API. >>>>>>>>> - Ex Creating a Jax-rs client/library to utilize by other >>>>>>>>> integration test. >>>>>>>>> >>>>>>>>> Thanks & Regards >>>>>>>>> Jo >>>>>>>>> >>>>>>>>> On Mon, Oct 19, 2015 at 12:17 PM, Joseph Fonseka <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Sorry mail got sent accidentally half written. will complete and >>>>>>>>>> send shortly. >>>>>>>>>> >>>>>>>>>> On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka <[email protected] >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Hi Sanjeewa >>>>>>>>>>> >>>>>>>>>>> Saneth & I had an offline chat regarding this last week there >>>>>>>>>>> are few things we need to consider. >>>>>>>>>>> >>>>>>>>>>> 1. Generating integration test for the Jax-RS functionality ex . >>>>>>>>>>> If crud operations work, if it returns correct error messages. >>>>>>>>>>> - We can use swagger-codegen to do this. >>>>>>>>>>> API Definition has all the details of the API interface what >>>>>>>>>>> missing are >>>>>>>>>>> >>>>>>>>>>> 2. How to get the existing integration test to utilize the new >>>>>>>>>>> API. >>>>>>>>>>> - We already have a lot of integration tests which uses >>>>>>>>>>> existing store & publisher APIs to add/remove resources. As Saneth >>>>>>>>>>> mention >>>>>>>>>>> they have written it in a layered architecture this replacing the >>>>>>>>>>> existing >>>>>>>>>>> API layer with Jax-rs existing test should work. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3. How to make it easy to write test in the future with Jax-Rs >>>>>>>>>>> API. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Team, >>>>>>>>>>>> We are planning to implement complete REST API for all >>>>>>>>>>>> operations available in API Manager. >>>>>>>>>>>> This will be CXF based jax-rs application. >>>>>>>>>>>> This application based on swagger template and service skeleton >>>>>>>>>>>> automatically generate according to swagger to cxf implementation >>>>>>>>>>>> done by >>>>>>>>>>>> Jo. >>>>>>>>>>>> We would like to know what would be the best approach to >>>>>>>>>>>> implement test for this service. >>>>>>>>>>>> Do we have any mechanism to generate client and test service in >>>>>>>>>>>> unit test level ? I can see there are projects to generate java >>>>>>>>>>>> client >>>>>>>>>>>> based on swagger content. >>>>>>>>>>>> Or do we need to write integration test to run this application >>>>>>>>>>>> in server and perform tests? >>>>>>>>>>>> Since this implementation changes rapidly it would be ideal if >>>>>>>>>>>> we can have skeleton based testing approach without binding to real >>>>>>>>>>>> implementation(like auto generated client). >>>>>>>>>>>> >>>>>>>>>>>> Have we done something similar? >>>>>>>>>>>> What would be the best approach? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> sanjeewa. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>> Mobile : +94713068779 >>>>>>>>>>>> >>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Dev mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Joseph Fonseka* >>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>> >>>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>>> skype: jpfonseka >>>>>>>>>>> >>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Joseph Fonseka* >>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>> lean.enterprise.middleware >>>>>>>>>> >>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>> skype: jpfonseka >>>>>>>>>> >>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Joseph Fonseka* >>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>> lean.enterprise.middleware >>>>>>>>> >>>>>>>>> mobile: +94 772 512 430 >>>>>>>>> skype: jpfonseka >>>>>>>>> >>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nuwan Dias >>>>>>>> >>>>>>>> Technical Lead - WSO2, Inc. http://wso2.com >>>>>>>> email : [email protected] >>>>>>>> Phone : +94 777 775 729 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> -- >>>>>>> *Joseph Fonseka* >>>>>>> WSO2 Inc.; http://wso2.com >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> mobile: +94 772 512 430 >>>>>>> skype: jpfonseka >>>>>>> >>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Sanjeewa Malalgoda* >>>>>> WSO2 Inc. >>>>>> Mobile : +94713068779 >>>>>> >>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Sanjeewa Malalgoda* >>>>> WSO2 Inc. >>>>> Mobile : +94713068779 >>>>> >>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Krishantha Samaraweera >>>> Senior Technical Lead - Test Automation >>>> Mobile: +94 77 7759918 >>>> WSO2, Inc.; http://wso2.com/ >>>> lean . enterprise . middleware. >>>> >>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >> >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> > > > -- > > 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 : +94770342233 > blog : http://dharshanaw.blogspot.com > > lean . enterprise . middleware >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
