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/integration/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/integration/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/integration/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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
