Hi, 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. > > *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. > +1 for option-3. With option-1 we have few limitations and option-2 is a bit messy and hard to maintain a clean code. According to the WSO2 REST API Standards we do use the swagger code gen tool to generate server stubs so IMHO this is the best option to write the the tests. Why didn't we try this option initially to write REST tests (instead of data driven framework??) and do we have any known drawbacks? Further, since we have customized the swagger code gen tool, we could also alter the client stub generation if required. > 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 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lahiru Cooray* Software Engineer WSO2, Inc.;http://wso2.com/ lean.enterprise.middleware Mobile: +94 715 654154
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
