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
