+1 to what Jo suggested, I have written some classes to already do this but haven't committed the code. @Malintha and Praminda, you can reuse these if you wish.
On 29 August 2016 at 12:00, Joseph Fonseka <[email protected]> wrote: > How about having the OAuth flow transparent to the test case developer ? > which will require one less step when writing a test case. > > We can achieve above by creating a Factory to get the Client with a token. > The Factory will deal with token generation probably talking to endpoints > in the configs. So its same as Util class but developer don't have to do it > by him self. > > Also in some cases we might want to test with a user other than admin in > that case we can pass user name to Factory or Utill class to get a client > with a user token. > > Regards > Jo > > > > On Mon, Aug 29, 2016 at 11:25 AM, Praminda Jayawardana <[email protected]> > wrote: > >> Hi Jo, >> >> I used a hardcoded dummy URL for the tokenUrl. >> >> In an offline discussion with Nuwan and Malintha we decided to have a >> separate Util class to handle the OAuth flow. Test case developer can use >> this Util class to create the OAuth app and generate the access token. Then >> that access token can be passed to the swagger client to invoke the APIs. >> Initializing the Util class with correct endpoints should be done by the >> test case developer when writing the test case (Read from the configs or >> hardcod). >> >> So can't we ignore the importance of "authorizationUrl/tokenUrl" values >> in this case? >> >> Thanks, >> Praminda >> >> On Mon, Aug 29, 2016 at 1:43 AM, Joseph Fonseka <[email protected]> wrote: >> >>> Hi Praminda >>> >>> How was the "authorizationUrl/tokenUrl" set to the security definitions >>> was it hardcoded or does it dynamically resolve the URL based on the setup. >>> Let say if we want to test a distributed deployment does it pick tokenUrl >>> may be from configs. >>> >>> Thanks >>> Jo >>> >>> On Mon, Aug 22, 2016 at 10:34 AM, Praminda Jayawardana < >>> [email protected]> wrote: >>> >>>> Hi, >>>> >>>> I tried out option 3 with store swagger file to find out if there are >>>> any limitations in the generated client to complete our task. I was able to >>>> generated a client library with swagger codegen. >>>> Only problem was, we don't have security definitions in our swagger >>>> files. Without that, codegen is not able to identify the APIs that require >>>> authorization. This means requests made to restricted resource using the >>>> generated client fails even if we set the correct access token. >>>> After updating the swagger file with security definitions client worked >>>> as expected. >>>> >>>> +1 for using option 3 >>>> >>>> Thanks, >>>> Praminda >>>> >>>> On Fri, Aug 19, 2016 at 2:50 PM, Nuwan Dias <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Aug 19, 2016 at 12:09 PM, Malintha Amarasinghe < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Existing test cases use following classes as Utils for >>>>>> store/publisher and admin operation which uses the existing jaggery api. >>>>>> >>>>>> Store - https://github.com/wso2/product-apim/blob/master/modules/int >>>>>> egration/tests-common/integration-test-utils/src/main/java/o >>>>>> rg/wso2/am/integration/test/utils/clients/APIStoreRestClient.java >>>>>> Publisher - https://github.com/wso2/produc >>>>>> t-apim/blob/master/modules/integration/tests-common/integrat >>>>>> ion-test-utils/src/main/java/org/wso2/am/integration/test/ut >>>>>> ils/clients/APIPublisherRestClient.java >>>>>> Admin - https://github.com/wso2/product-apim/blob/master/modules/int >>>>>> egration/tests-common/integration-test-utils/src/main/java/o >>>>>> rg/wso2/am/integration/test/utils/clients/AdminDashboardRest >>>>>> Client.java >>>>>> >>>>>> So we have following options: >>>>>> >>>>>> *Option 1: Writing test cases using data driven test module.* >>>>>> *Pros:* >>>>>> Simple to write test cases. >>>>>> >>>>>> *Cons:* >>>>>> Not all test cases cases can be written using this. >>>>>> >>>>> >>>>> Another Con I see is that you will have to maintain a lot of JSON >>>>> payloads all over the place. A change in the REST API would mean we have >>>>> to >>>>> change all of that. Yes, we can template and minimise the duplicates up to >>>>> a certain extent but still I think we will end up with lots of complicated >>>>> payloads. >>>>> >>>>>> >>>>>> *Option 2: Re-writing the above test classes so that minimal amount >>>>>> of change is needed to do to the existing test classes.* >>>>>> For example: We have a method to create an API in publisher util >>>>>> class which is currently using jaggery api. We can change the method body >>>>>> to use the CXF REST API and create an API using that. Using the same >>>>>> arguments which come into the method. >>>>>> >>>>>> *Pros:* >>>>>> Needs minimal amount of changes to the existing tests >>>>>> >>>>>> *Cons:* >>>>>> They are using HttpResponse object as the method return type and at >>>>>> the test case level it directly access the parameters in the payload. So >>>>>> to >>>>>> handle the response, we need to do changes at the Test cases level >>>>>> anyway. >>>>>> If we use Swagger based client library with this, we need to write >>>>>> some mapping classes to convert data from/to existing beans and swagger >>>>>> generated beans which is an additional effort. >>>>>> Code won't be very clean after all. >>>>>> >>>>>> *Option 3: Completely moving to the generated client modules >>>>>> generated using swagger* >>>>>> Then we need to completely change the existing test cases to use the >>>>>> generated clients instead of using the above 3 util classes. Will need to >>>>>> do many changes but after all, we will have a clean code that consumes >>>>>> the >>>>>> new REST API. >>>>>> >>>>> >>>>> I personally would prefer to explore on option 3. This would give a >>>>> lot more clean code and we can use code-gen to generate the stubs too. So >>>>> if we do it right we could avoid a lot of manual code. >>>>> >>>>>> >>>>>> Thanks! >>>>>> Malintha >>>>>> >>>>>> On Fri, Aug 19, 2016 at 8:58 AM, Sanjeewa Malalgoda < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> +1. My suggestion is to improve and use data driven test utility we >>>>>>> already implemented. >>>>>>> When all other products move ahead with REST APIs we need to have >>>>>>> well define protocol to implement tests for them like we do in API >>>>>>> implementation. >>>>>>> With this approach even person who do not familiar with coding stuff >>>>>>> can still implement test cases using JSON test case. >>>>>>> >>>>>>> Thanks, >>>>>>> sanjeewa. >>>>>>> >>>>>>> On Thu, Aug 18, 2016 at 10:39 PM, Malintha Amarasinghe < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> We are working on modifying the existing test cases based on old >>>>>>>> jaggery APIs which is deprecated to use the new REST APIs based on CXF. >>>>>>>> Since the new REST APIs are designed using swagger based, we can >>>>>>>> generate >>>>>>>> client libraries for each publisher/store and admin REST APIs using >>>>>>>> swagger >>>>>>>> and use them in test cases. >>>>>>>> >>>>>>>> *Objectives of this task:* >>>>>>>> 1. Jaggery APIs are deprecated so we need to gradually move the >>>>>>>> code we are using them to use the new REST API. >>>>>>>> 2. Find the limitations of the REST APIs and fix them while we are >>>>>>>> writing the tests which will help REST APIs to stabilize. >>>>>>>> >>>>>>>> On a separate note, we can also consider improving the existing >>>>>>>> data driven tests module for the REST APIs. >>>>>>>> >>>>>>>> 1. Remove hardcoded payloads and use a proper way since its >>>>>>>> difficult to maintain them when API changes happens (need to change >>>>>>>> many >>>>>>>> duplicated places where payloads hardcoded). [1] >>>>>>>> 2. Proper assertion handling. >>>>>>>> >>>>>>>> @Praminda, please add anything if I have missed. >>>>>>>> >>>>>>>> Appreciate your thoughts on this. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Malintha >>>>>>>> >>>>>>>> [1] https://github.com/wso2/product-apim/blob/master/modules >>>>>>>> /integration/tests-integration/tests-backend/src/test/resour >>>>>>>> ces/rest-api-test-data/APITestCase.txt >>>>>>>> -- >>>>>>>> Malintha Amarasinghe >>>>>>>> Software Engineer >>>>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>>>> http://wso2.com/ >>>>>>>> >>>>>>>> Mobile : +94 712383306 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Sanjeewa Malalgoda* >>>>>>> WSO2 Inc. >>>>>>> Mobile : +94713068779 >>>>>>> >>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Malintha Amarasinghe >>>>>> Software Engineer >>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>> http://wso2.com/ >>>>>> >>>>>> Mobile : +94 712383306 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Nuwan Dias >>>>> >>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>> email : [email protected] >>>>> Phone : +94 777 775 729 >>>>> >>>> >>>> >>>> >>>> -- >>>> *Praminda Jayawardana* >>>> Software Engineer >>>> WSO2 Inc.; http://wso2.com >>>> Mobile : +94 (0) 716 590918 >>>> >>>> >>> >>> >>> -- >>> >>> -- >>> *Joseph Fonseka* >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 772 512 430 >>> skype: jpfonseka >>> >>> * <http://lk.linkedin.com/in/rumeshbandara>* >>> >>> >> >> >> -- >> *Praminda Jayawardana* >> Software Engineer >> WSO2 Inc.; http://wso2.com >> Mobile : +94 (0) 716 590918 >> >> <https://wso2.com/signature> >> > > > > -- > > -- > *Joseph Fonseka* > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 772 512 430 > skype: jpfonseka > > * <http://lk.linkedin.com/in/rumeshbandara>* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
