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/ >>> org/wso2/am/integration/test/utils/clients/APIStoreRestClient.java >>> Publisher - https://github.com/wso2/product-apim/blob/master/modules/int >>> egration/tests-common/integration-test-utils/src/main/java/ >>> org/wso2/am/integration/test/utils/clients/APIPublisherRestClient.java >>> Admin - https://github.com/wso2/product-apim/blob/master/modules/int >>> egration/tests-common/integration-test-utils/src/main/java/ >>> org/wso2/am/integration/test/utils/clients/AdminDashboardRestClient.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>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
