Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Chamin Dias]

Hi,

We have come up with a mechanism to include automated tests for the REST
API which is going to be shipped with APIM 1.10.0. This is a data driven
test mechanism. The purpose of this E-Mail is to communicate the method
that we used to do the required task.

The test automation process has several java files, data files (in JSON
format)


*Data file*

Data for each scenario is stored in JSON format. Here is an example.

{
"testCase": [
{
"init": {
"scope": ""
},
"data": {
"method": "",
"url": "",
"query-parameters": "",
"request-headers": {
"Authorization": "Bearer"
},
"request-payload": "",
"response-headers": "",
"response-payload": ""
},
"asserts": {
"header-asserts": {
"status-code": ""
},
"body-asserts": ""
}
}
]
}


In a test case, there are three main sections named "init", "data" and
"asserts". Init section is used to store the user scope which is needed to
register the OAuth app and generate the access token. Data section will
store the required data for the corresponding request. It includes the HTTP
method, URL, query parameters (in nested JSON element), request-headers,
request-payload and response-headers. Asserts section is there to hold the
fields that are going to be validated against the response. Values that are
in header/body or both header and body can be compared to verify the
response.

In addition to that, we are going to include another section called
"preserve-list", if we need to take some of the values from the current
response to the next request. If this section is there, then the parameter
is stored in a Map (in the code) , as it needs to be used in subsequent
request(s).

Example : If we add (POST) a new API from the first request and if are
going to fetch it at the next request (GET), then we need to store the UUID
of the created API in the second request. In those kind of scenarios, this
"preserve-list" will be used. It contains the name of the attribute to be
preserved and the location of that attribute in the response, which is
represented in JSON format. For example, the following "preserve-list" says
that, it is needed to preserve the "apiId", which can be found in "id"
element in the response.

 "preserve-list":[
{
"attribute-name":"apiId",
"response-location":"id"

}
]


If there is a resource URL like /api/am/publisher/v1//apis/{apiId}, then
the {apiId} will be fetched from the preserved list and the URL for the
request is constructed accordingly. Please note that this "preserve-list"
is optional. It is *only* needed if we need to take some value for the next
request.

The next important section is the "asserts" section. This is mainly for the
verification process to evaluate wether the test has succeeded or not.
"header-asserts" section contains the elements that should be compared
against the header of the response, while "body-asserts"


*Util Java files*

We have created util classes that can be used in any test scenario. The
util classes do the following tasks.

i) Read the data file
ii) Parse the data (i.e JSON)
iii) Register an OAuth application
iv) Generate access token (using token API)
v) Put the attributes to the preserve attribute list(if needed)
vi) Send the request to the REST API
vii) Identify the type of the request and make the relevant call (GET,POST
etc..)
viii) Get the response

These util methods are used in all test scenarios. If all the test cases
for a given scenario is successful, then we evaluate the test has passed.

Eg : If the test scenario is manipulating tiers, we first add a tier, GET
the tier, update the tier and delete the tier via the REST API. If all of
them are succeeded, we assert that the tier manipulation test has passed.


*Some more facts about this model*

If we need to add a new test scenario, all we need to do is, add a java
file only for the corresponding test, add the corresponding JSON data file
and run it. If we need to add/remove a request to/from a test scenario, all
we need to do is add/remove the required JSON configuration, save it and
run the test. Util classes won't change.

We have done R and discussions on selection this mechanism and we have
found that this is the most flexible approach to write test cases for the
REST API. In addition to that, we think this data driven approach can be
used in similar situations in other products as well. Eventually, we hope
this model will be beneficial when trying to come up with a automation
mechanism for all WSO2 products.

Thanks.
ChaminD

On Tue, Nov 24, 2015 at 11:47 AM, Dharshana 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Sanjeewa Malalgoda]

Excellent job Chamin.
This will be really cool module and we can use it for all REST API test
scenarios across platform.

Thanks,
sanjeewa.



On Mon, Dec 14, 2015 at 11:00 AM, Chamin Dias  wrote:

> Hi,
>
> We have come up with a mechanism to include automated tests for the REST
> API which is going to be shipped with APIM 1.10.0. This is a data driven
> test mechanism. The purpose of this E-Mail is to communicate the method
> that we used to do the required task.
>
> The test automation process has several java files, data files (in JSON
> format)
>
>
> *Data file*
>
> Data for each scenario is stored in JSON format. Here is an example.
>
> {
> "testCase": [
> {
> "init": {
> "scope": ""
> },
> "data": {
> "method": "",
> "url": "",
> "query-parameters": "",
> "request-headers": {
> "Authorization": "Bearer"
> },
> "request-payload": "",
> "response-headers": "",
> "response-payload": ""
> },
> "asserts": {
> "header-asserts": {
> "status-code": ""
> },
> "body-asserts": ""
> }
> }
> ]
> }
>
>
> In a test case, there are three main sections named "init", "data" and
> "asserts". Init section is used to store the user scope which is needed to
> register the OAuth app and generate the access token. Data section will
> store the required data for the corresponding request. It includes the HTTP
> method, URL, query parameters (in nested JSON element), request-headers,
> request-payload and response-headers. Asserts section is there to hold the
> fields that are going to be validated against the response. Values that are
> in header/body or both header and body can be compared to verify the
> response.
>
> In addition to that, we are going to include another section called
> "preserve-list", if we need to take some of the values from the current
> response to the next request. If this section is there, then the parameter
> is stored in a Map (in the code) , as it needs to be used in subsequent
> request(s).
>
> Example : If we add (POST) a new API from the first request and if are
> going to fetch it at the next request (GET), then we need to store the UUID
> of the created API in the second request. In those kind of scenarios, this
> "preserve-list" will be used. It contains the name of the attribute to be
> preserved and the location of that attribute in the response, which is
> represented in JSON format. For example, the following "preserve-list" says
> that, it is needed to preserve the "apiId", which can be found in "id"
> element in the response.
>
>  "preserve-list":[
> {
> "attribute-name":"apiId",
> "response-location":"id"
>
> }
> ]
>
>
> If there is a resource URL like /api/am/publisher/v1//apis/{apiId}, then
> the {apiId} will be fetched from the preserved list and the URL for the
> request is constructed accordingly. Please note that this "preserve-list"
> is optional. It is *only* needed if we need to take some value for the
> next request.
>
> The next important section is the "asserts" section. This is mainly for
> the verification process to evaluate wether the test has succeeded or not.
> "header-asserts" section contains the elements that should be compared
> against the header of the response, while "body-asserts"
>
>
> *Util Java files*
>
> We have created util classes that can be used in any test scenario. The
> util classes do the following tasks.
>
> i) Read the data file
> ii) Parse the data (i.e JSON)
> iii) Register an OAuth application
> iv) Generate access token (using token API)
> v) Put the attributes to the preserve attribute list(if needed)
> vi) Send the request to the REST API
> vii) Identify the type of the request and make the relevant call (GET,POST
> etc..)
> viii) Get the response
>
> These util methods are used in all test scenarios. If all the test cases
> for a given scenario is successful, then we evaluate the test has passed.
>
> Eg : If the test scenario is manipulating tiers, we first add a tier, GET
> the tier, update the tier and delete the tier via the REST API. If all of
> them are succeeded, we assert that the tier manipulation test has passed.
>
>
> *Some more facts about this model*
>
> If we need to add a new test scenario, all we need to do is, add a java
> file only for the corresponding test, add the corresponding JSON data file
> and run it. If we need to add/remove a request to/from a test scenario, all
> we need to do is add/remove the required JSON configuration, save it and
> run the test. Util classes won't change.
>
> We have done R and 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Dharshana Warusavitharana]

Hi Sanjeewa,

Sorry for late reply , some how i missed this.
Please use following versions on dependencies

2.0.0.wso2v1
3.0.2.Final
2.0.1


And place the dependency with scope of compile so that won't conflict with
other dependencies.


org.jboss.resteasy
resteasy-client
compile


Thank you,

Dharshana.



On Mon, Nov 23, 2015 at 12:13 PM, Sanjeewa Malalgoda 
wrote:

> @dharshana can you confirm rest easy version we should use in Apim 1.10x.
> It seems http client version conflict happen in automation tests due to
> obove import.
>
> Thanks
> sanjeewa.
>
> sent from my phone
> On Nov 20, 2015 2:37 PM, "Dharshana Warusavitharana" 
> wrote:
>
>> Hi Sanjeewa,
>>
>> This is ok to add these dependencies but for jax-rs please refer the
>> jax-rs wso2 version that used in the product. Else there will be confilcts.
>>
>> Thank you,
>> Dharshana.
>>
>> On Fri, Nov 20, 2015 at 2:29 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> Hi Team,
>>> While implementing test case as per sample provided by dharshanaW i
>>> wanted add following dependencies to test back end pom.
>>>
>>> 
>>> javax.ws.rs
>>> javax.ws.rs-api
>>> 2.0.1
>>> 
>>>
>>> org.jboss.resteasy
>>> resteasy-client
>>> 3.0.2.Final
>>>
>>> Is it ok if added these dependencies to back end tests module?
>>> We have implemented generic data driven test utility class and we may
>>> move it to automation core as its common requirement.
>>> Its main methods input parameters as follows.
>>>
>>> testRestAPI(String url, String requestPayLoad, Map
>>> header, Map queryParams,
>>>   String responsePayLoad)
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>
>>>
>>> On Wed, Nov 18, 2015 at 4:58 PM, Sanjeewa Malalgoda 
>>> wrote:
>>>
 As per discussion with automation test team our plan is to implement
 data driven test cases for this.
 With that we will be able to define request data and expected response
 data.
 The utility class we are going to implement will take request data and
 then validate response with provided response.
 If the API got changed in future we do not need to change test.
 We can simply change the data set as per new API.
 This approach will help us to implement test easily and manage them.

 Please let us know your thought on this.

 Thanks,
 sanjeewa.


 On Tue, Nov 3, 2015 at 5:49 PM, Krishantha Samaraweera <
 krishan...@wso2.com> wrote:

> Hi Sanjeewa
>
> On Tue, Oct 20, 2015 at 2:47 PM, Sanjeewa Malalgoda  > wrote:
>
>> QAA team shall we have discussion on this and come to conclusion?
>> Please let us know possible time slots.
>>
>
> +1 shall we meet this week.
>
> Thanks,
> Krishantha.
>
>>
>> Thanks,
>> sanjeewa.
>>
>> On Mon, Oct 19, 2015 at 12:44 PM, Sanjeewa Malalgoda <
>> sanje...@wso2.com> wrote:
>>
>>> Here idea is easily manage the tests and web application.
>>> Since web application purely depend on swagger definition it will
>>> automatically generate beans, service skeletons etc.
>>>
>>> So in same way if we implement test cases we don't have to go and
>>> edit test case code after we adding new parameters or something like 
>>> that.
>>> What we can simply do is change sample data set feed into test.
>>>
>>>
>>>
>>> On Mon, Oct 19, 2015 at 12:34 PM, Joseph Fonseka 
>>> wrote:
>>>
 Hi Nuwan

 Thanks for pointing that out, in that case test can be version-ed
 so auto generated tests for version 1.0.0 should work with API 1.0.1 
 ...

 WDYT?

 Regards
 Jo

 On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias 
 wrote:

> Is it right to auto-generate the test client code? IMO one
> objective of this should be to make sure the REST APIs don't change 
> across
> patch releases, etc. If we auto-generate the test stubs we would 
> loose that
> advantage.
>
 I don't get how we loose advantage here.
>>> If we don't want to change service API we don't have to edit swagger
>>> json and that is it.
>>> Then it will not change service API, neither test client or data set
>>> feed in to test.
>>> If we consider both integration and unit tests those will be
>>> released anyway with product and component release.
>>> So tests will be automatically version-ed with component/product
>>> version.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>

> Thanks,
> NuwanD.
>
> On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Sanjeewa Malalgoda]

@dharshana can you confirm rest easy version we should use in Apim 1.10x.
It seems http client version conflict happen in automation tests due to
obove import.

Thanks
sanjeewa.

sent from my phone
On Nov 20, 2015 2:37 PM, "Dharshana Warusavitharana" 
wrote:

> Hi Sanjeewa,
>
> This is ok to add these dependencies but for jax-rs please refer the
> jax-rs wso2 version that used in the product. Else there will be confilcts.
>
> Thank you,
> Dharshana.
>
> On Fri, Nov 20, 2015 at 2:29 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi Team,
>> While implementing test case as per sample provided by dharshanaW i
>> wanted add following dependencies to test back end pom.
>>
>> 
>> javax.ws.rs
>> javax.ws.rs-api
>> 2.0.1
>> 
>>
>> org.jboss.resteasy
>> resteasy-client
>> 3.0.2.Final
>>
>> Is it ok if added these dependencies to back end tests module?
>> We have implemented generic data driven test utility class and we may
>> move it to automation core as its common requirement.
>> Its main methods input parameters as follows.
>>
>> testRestAPI(String url, String requestPayLoad, Map header,
>> Map queryParams,
>>   String responsePayLoad)
>>
>> Thanks,
>> sanjeewa.
>>
>>
>>
>> On Wed, Nov 18, 2015 at 4:58 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> As per discussion with automation test team our plan is to implement
>>> data driven test cases for this.
>>> With that we will be able to define request data and expected response
>>> data.
>>> The utility class we are going to implement will take request data and
>>> then validate response with provided response.
>>> If the API got changed in future we do not need to change test.
>>> We can simply change the data set as per new API.
>>> This approach will help us to implement test easily and manage them.
>>>
>>> Please let us know your thought on this.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>
>>> On Tue, Nov 3, 2015 at 5:49 PM, Krishantha Samaraweera <
>>> krishan...@wso2.com> wrote:
>>>
 Hi Sanjeewa

 On Tue, Oct 20, 2015 at 2:47 PM, Sanjeewa Malalgoda 
 wrote:

> QAA team shall we have discussion on this and come to conclusion?
> Please let us know possible time slots.
>

 +1 shall we meet this week.

 Thanks,
 Krishantha.

>
> Thanks,
> sanjeewa.
>
> On Mon, Oct 19, 2015 at 12:44 PM, Sanjeewa Malalgoda <
> sanje...@wso2.com> wrote:
>
>> Here idea is easily manage the tests and web application.
>> Since web application purely depend on swagger definition it will
>> automatically generate beans, service skeletons etc.
>>
>> So in same way if we implement test cases we don't have to go and
>> edit test case code after we adding new parameters or something like 
>> that.
>> What we can simply do is change sample data set feed into test.
>>
>>
>>
>> On Mon, Oct 19, 2015 at 12:34 PM, Joseph Fonseka 
>> wrote:
>>
>>> Hi Nuwan
>>>
>>> Thanks for pointing that out, in that case test can be version-ed so
>>> auto generated tests for version 1.0.0 should work with API 1.0.1 ...
>>>
>>> WDYT?
>>>
>>> Regards
>>> Jo
>>>
>>> On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias 
>>> wrote:
>>>
 Is it right to auto-generate the test client code? IMO one
 objective of this should be to make sure the REST APIs don't change 
 across
 patch releases, etc. If we auto-generate the test stubs we would loose 
 that
 advantage.

>>> I don't get how we loose advantage here.
>> If we don't want to change service API we don't have to edit swagger
>> json and that is it.
>> Then it will not change service API, neither test client or data set
>> feed in to test.
>> If we consider both integration and unit tests those will be released
>> anyway with product and component release.
>> So tests will be automatically version-ed with component/product
>> version.
>>
>> Thanks,
>> sanjeewa.
>>
>>
>>>
 Thanks,
 NuwanD.

 On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka 
 wrote:

> Hi Sanjeewa
>
> Saneth & I had an offline chat regarding this last week there are
> few things we need to consider.
>
> 1. Generating integration test for the Jax-RS functionality ex .
> If crud operations work, if it returns correct error messages.
>  -  We can use swagger-codegen to do this.
>  -  API Definition has all the details of the API
> interface what missing are the data fixtures.
>  - There are few 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Sanjeewa Malalgoda]

Hi Team,
While implementing test case as per sample provided by dharshanaW i wanted
add following dependencies to test back end pom.


javax.ws.rs
javax.ws.rs-api
2.0.1

   
org.jboss.resteasy
resteasy-client
3.0.2.Final

Is it ok if added these dependencies to back end tests module?
We have implemented generic data driven test utility class and we may move
it to automation core as its common requirement.
Its main methods input parameters as follows.

testRestAPI(String url, String requestPayLoad, Map header,
Map queryParams,
  String responsePayLoad)

Thanks,
sanjeewa.



On Wed, Nov 18, 2015 at 4:58 PM, Sanjeewa Malalgoda 
wrote:

> As per discussion with automation test team our plan is to implement data
> driven test cases for this.
> With that we will be able to define request data and expected response
> data.
> The utility class we are going to implement will take request data and
> then validate response with provided response.
> If the API got changed in future we do not need to change test.
> We can simply change the data set as per new API.
> This approach will help us to implement test easily and manage them.
>
> Please let us know your thought on this.
>
> Thanks,
> sanjeewa.
>
>
> On Tue, Nov 3, 2015 at 5:49 PM, Krishantha Samaraweera <
> krishan...@wso2.com> wrote:
>
>> Hi Sanjeewa
>>
>> On Tue, Oct 20, 2015 at 2:47 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> QAA team shall we have discussion on this and come to conclusion?
>>> Please let us know possible time slots.
>>>
>>
>> +1 shall we meet this week.
>>
>> Thanks,
>> Krishantha.
>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Mon, Oct 19, 2015 at 12:44 PM, Sanjeewa Malalgoda 
>>> wrote:
>>>
 Here idea is easily manage the tests and web application.
 Since web application purely depend on swagger definition it will
 automatically generate beans, service skeletons etc.

 So in same way if we implement test cases we don't have to go and edit
 test case code after we adding new parameters or something like that.
 What we can simply do is change sample data set feed into test.



 On Mon, Oct 19, 2015 at 12:34 PM, Joseph Fonseka 
 wrote:

> Hi Nuwan
>
> Thanks for pointing that out, in that case test can be version-ed so
> auto generated tests for version 1.0.0 should work with API 1.0.1 ...
>
> WDYT?
>
> Regards
> Jo
>
> On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias  wrote:
>
>> Is it right to auto-generate the test client code? IMO one objective
>> of this should be to make sure the REST APIs don't change across patch
>> releases, etc. If we auto-generate the test stubs we would loose that
>> advantage.
>>
> I don't get how we loose advantage here.
 If we don't want to change service API we don't have to edit swagger
 json and that is it.
 Then it will not change service API, neither test client or data set
 feed in to test.
 If we consider both integration and unit tests those will be released
 anyway with product and component release.
 So tests will be automatically version-ed with component/product
 version.

 Thanks,
 sanjeewa.


>
>> Thanks,
>> NuwanD.
>>
>> On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka 
>> wrote:
>>
>>> Hi Sanjeewa
>>>
>>> Saneth & I had an offline chat regarding this last week there are
>>> few things we need to consider.
>>>
>>> 1. Generating integration test for the Jax-RS functionality ex . If
>>> crud operations work, if it returns correct error messages.
>>>  -  We can use swagger-codegen to do this.
>>>  -  API Definition has all the details of the API interface
>>> what missing are the data fixtures.
>>>  - There are few options with the fixtures which we can auto
>>> generate since the schema of the model is there or we can use a 
>>> predefined
>>> set of json files.
>>>
>>> 2. How to get the existing integration test to utilize the new API.
>>>  - We already have a lot of integration tests which uses
>>> existing store & publisher APIs to add/remove resources. As Saneth 
>>> mention
>>> they have written it in a layered architecture this replacing the 
>>> existing
>>> API layer with Jax-rs existing test should work.
>>>  - We might have to look at this in the next phase when we
>>> plan to deprecate the existing APIs.
>>>
>>> 3. How to make it easy to write test in the future with Jax-Rs API.
>>>  - Ex Creating a Jax-rs client/library to utilize by other
>>> integration test.
>>>
>>> Thanks 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Dharshana Warusavitharana]

Hi Sanjeewa,

This is ok to add these dependencies but for jax-rs please refer the jax-rs
wso2 version that used in the product. Else there will be confilcts.

Thank you,
Dharshana.

On Fri, Nov 20, 2015 at 2:29 PM, Sanjeewa Malalgoda 
wrote:

> Hi Team,
> While implementing test case as per sample provided by dharshanaW i wanted
> add following dependencies to test back end pom.
>
> 
> javax.ws.rs
> javax.ws.rs-api
> 2.0.1
> 
>
> org.jboss.resteasy
> resteasy-client
> 3.0.2.Final
>
> Is it ok if added these dependencies to back end tests module?
> We have implemented generic data driven test utility class and we may move
> it to automation core as its common requirement.
> Its main methods input parameters as follows.
>
> testRestAPI(String url, String requestPayLoad, Map header,
> Map queryParams,
>   String responsePayLoad)
>
> Thanks,
> sanjeewa.
>
>
>
> On Wed, Nov 18, 2015 at 4:58 PM, Sanjeewa Malalgoda 
> wrote:
>
>> As per discussion with automation test team our plan is to implement data
>> driven test cases for this.
>> With that we will be able to define request data and expected response
>> data.
>> The utility class we are going to implement will take request data and
>> then validate response with provided response.
>> If the API got changed in future we do not need to change test.
>> We can simply change the data set as per new API.
>> This approach will help us to implement test easily and manage them.
>>
>> Please let us know your thought on this.
>>
>> Thanks,
>> sanjeewa.
>>
>>
>> On Tue, Nov 3, 2015 at 5:49 PM, Krishantha Samaraweera <
>> krishan...@wso2.com> wrote:
>>
>>> Hi Sanjeewa
>>>
>>> On Tue, Oct 20, 2015 at 2:47 PM, Sanjeewa Malalgoda 
>>> wrote:
>>>
 QAA team shall we have discussion on this and come to conclusion?
 Please let us know possible time slots.

>>>
>>> +1 shall we meet this week.
>>>
>>> Thanks,
>>> Krishantha.
>>>

 Thanks,
 sanjeewa.

 On Mon, Oct 19, 2015 at 12:44 PM, Sanjeewa Malalgoda  wrote:

> Here idea is easily manage the tests and web application.
> Since web application purely depend on swagger definition it will
> automatically generate beans, service skeletons etc.
>
> So in same way if we implement test cases we don't have to go and edit
> test case code after we adding new parameters or something like that.
> What we can simply do is change sample data set feed into test.
>
>
>
> On Mon, Oct 19, 2015 at 12:34 PM, Joseph Fonseka 
> wrote:
>
>> Hi Nuwan
>>
>> Thanks for pointing that out, in that case test can be version-ed so
>> auto generated tests for version 1.0.0 should work with API 1.0.1 ...
>>
>> WDYT?
>>
>> Regards
>> Jo
>>
>> On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias  wrote:
>>
>>> Is it right to auto-generate the test client code? IMO one objective
>>> of this should be to make sure the REST APIs don't change across patch
>>> releases, etc. If we auto-generate the test stubs we would loose that
>>> advantage.
>>>
>> I don't get how we loose advantage here.
> If we don't want to change service API we don't have to edit swagger
> json and that is it.
> Then it will not change service API, neither test client or data set
> feed in to test.
> If we consider both integration and unit tests those will be released
> anyway with product and component release.
> So tests will be automatically version-ed with component/product
> version.
>
> Thanks,
> sanjeewa.
>
>
>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka 
>>> wrote:
>>>
 Hi Sanjeewa

 Saneth & I had an offline chat regarding this last week there are
 few things we need to consider.

 1. Generating integration test for the Jax-RS functionality ex . If
 crud operations work, if it returns correct error messages.
  -  We can use swagger-codegen to do this.
  -  API Definition has all the details of the API interface
 what missing are the data fixtures.
  - There are few options with the fixtures which we can
 auto generate since the schema of the model is there or we can use a
 predefined set of json files.

 2. How to get the existing integration test to utilize the new API.
  - We already have a lot of integration tests which uses
 existing store & publisher APIs to add/remove resources. As Saneth 
 mention
 they have written it in a layered architecture 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Sanjeewa Malalgoda]

As per discussion with automation test team our plan is to implement data
driven test cases for this.
With that we will be able to define request data and expected response
data.
The utility class we are going to implement will take request data and then
validate response with provided response.
If the API got changed in future we do not need to change test.
We can simply change the data set as per new API.
This approach will help us to implement test easily and manage them.

Please let us know your thought on this.

Thanks,
sanjeewa.


On Tue, Nov 3, 2015 at 5:49 PM, Krishantha Samaraweera 
wrote:

> Hi Sanjeewa
>
> On Tue, Oct 20, 2015 at 2:47 PM, Sanjeewa Malalgoda 
> wrote:
>
>> QAA team shall we have discussion on this and come to conclusion?
>> Please let us know possible time slots.
>>
>
> +1 shall we meet this week.
>
> Thanks,
> Krishantha.
>
>>
>> Thanks,
>> sanjeewa.
>>
>> On Mon, Oct 19, 2015 at 12:44 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> Here idea is easily manage the tests and web application.
>>> Since web application purely depend on swagger definition it will
>>> automatically generate beans, service skeletons etc.
>>>
>>> So in same way if we implement test cases we don't have to go and edit
>>> test case code after we adding new parameters or something like that.
>>> What we can simply do is change sample data set feed into test.
>>>
>>>
>>>
>>> On Mon, Oct 19, 2015 at 12:34 PM, Joseph Fonseka 
>>> wrote:
>>>
 Hi Nuwan

 Thanks for pointing that out, in that case test can be version-ed so
 auto generated tests for version 1.0.0 should work with API 1.0.1 ...

 WDYT?

 Regards
 Jo

 On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias  wrote:

> Is it right to auto-generate the test client code? IMO one objective
> of this should be to make sure the REST APIs don't change across patch
> releases, etc. If we auto-generate the test stubs we would loose that
> advantage.
>
 I don't get how we loose advantage here.
>>> If we don't want to change service API we don't have to edit swagger
>>> json and that is it.
>>> Then it will not change service API, neither test client or data set
>>> feed in to test.
>>> If we consider both integration and unit tests those will be released
>>> anyway with product and component release.
>>> So tests will be automatically version-ed with component/product version.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>

> Thanks,
> NuwanD.
>
> On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka 
> wrote:
>
>> Hi Sanjeewa
>>
>> Saneth & I had an offline chat regarding this last week there are few
>> things we need to consider.
>>
>> 1. Generating integration test for the Jax-RS functionality ex . If
>> crud operations work, if it returns correct error messages.
>>  -  We can use swagger-codegen to do this.
>>  -  API Definition has all the details of the API interface
>> what missing are the data fixtures.
>>  - There are few options with the fixtures which we can auto
>> generate since the schema of the model is there or we can use a 
>> predefined
>> set of json files.
>>
>> 2. How to get the existing integration test to utilize the new API.
>>  - We already have a lot of integration tests which uses
>> existing store & publisher APIs to add/remove resources. As Saneth 
>> mention
>> they have written it in a layered architecture this replacing the 
>> existing
>> API layer with Jax-rs existing test should work.
>>  - We might have to look at this in the next phase when we
>> plan to deprecate the existing APIs.
>>
>> 3. How to make it easy to write test in the future with Jax-Rs API.
>>  - Ex Creating a Jax-rs client/library to utilize by other
>> integration test.
>>
>> Thanks & Regards
>> Jo
>>
>> On Mon, Oct 19, 2015 at 12:17 PM, Joseph Fonseka 
>> wrote:
>>
>>> Sorry mail got sent accidentally half written. will complete and
>>> send shortly.
>>>
>>> On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka 
>>> wrote:
>>>
 Hi Sanjeewa

 Saneth & I had an offline chat regarding this last week there are
 few things we need to consider.

 1. Generating integration test for the Jax-RS functionality ex . If
 crud operations work, if it returns correct error messages.
  -  We can use swagger-codegen to do this.
  API Definition has all the details of the API interface what
 missing are

 2. How to get the existing integration test to utilize the new API.
  - We already have a lot of integration tests which uses
 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Krishantha Samaraweera]

Hi Sanjeewa

On Tue, Oct 20, 2015 at 2:47 PM, Sanjeewa Malalgoda 
wrote:

> QAA team shall we have discussion on this and come to conclusion?
> Please let us know possible time slots.
>

+1 shall we meet this week.

Thanks,
Krishantha.

>
> Thanks,
> sanjeewa.
>
> On Mon, Oct 19, 2015 at 12:44 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Here idea is easily manage the tests and web application.
>> Since web application purely depend on swagger definition it will
>> automatically generate beans, service skeletons etc.
>>
>> So in same way if we implement test cases we don't have to go and edit
>> test case code after we adding new parameters or something like that.
>> What we can simply do is change sample data set feed into test.
>>
>>
>>
>> On Mon, Oct 19, 2015 at 12:34 PM, Joseph Fonseka  wrote:
>>
>>> Hi Nuwan
>>>
>>> Thanks for pointing that out, in that case test can be version-ed so
>>> auto generated tests for version 1.0.0 should work with API 1.0.1 ...
>>>
>>> WDYT?
>>>
>>> Regards
>>> Jo
>>>
>>> On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias  wrote:
>>>
 Is it right to auto-generate the test client code? IMO one objective of
 this should be to make sure the REST APIs don't change across patch
 releases, etc. If we auto-generate the test stubs we would loose that
 advantage.

>>> I don't get how we loose advantage here.
>> If we don't want to change service API we don't have to edit swagger json
>> and that is it.
>> Then it will not change service API, neither test client or data set feed
>> in to test.
>> If we consider both integration and unit tests those will be released
>> anyway with product and component release.
>> So tests will be automatically version-ed with component/product version.
>>
>> Thanks,
>> sanjeewa.
>>
>>
>>>
 Thanks,
 NuwanD.

 On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka 
 wrote:

> Hi Sanjeewa
>
> Saneth & I had an offline chat regarding this last week there are few
> things we need to consider.
>
> 1. Generating integration test for the Jax-RS functionality ex . If
> crud operations work, if it returns correct error messages.
>  -  We can use swagger-codegen to do this.
>  -  API Definition has all the details of the API interface
> what missing are the data fixtures.
>  - There are few options with the fixtures which we can auto
> generate since the schema of the model is there or we can use a predefined
> set of json files.
>
> 2. How to get the existing integration test to utilize the new API.
>  - We already have a lot of integration tests which uses
> existing store & publisher APIs to add/remove resources. As Saneth mention
> they have written it in a layered architecture this replacing the existing
> API layer with Jax-rs existing test should work.
>  - We might have to look at this in the next phase when we
> plan to deprecate the existing APIs.
>
> 3. How to make it easy to write test in the future with Jax-Rs API.
>  - Ex Creating a Jax-rs client/library to utilize by other
> integration test.
>
> Thanks & Regards
> Jo
>
> On Mon, Oct 19, 2015 at 12:17 PM, Joseph Fonseka 
> wrote:
>
>> Sorry mail got sent accidentally half written. will complete and send
>> shortly.
>>
>> On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka 
>> wrote:
>>
>>> Hi Sanjeewa
>>>
>>> Saneth & I had an offline chat regarding this last week there are
>>> few things we need to consider.
>>>
>>> 1. Generating integration test for the Jax-RS functionality ex . If
>>> crud operations work, if it returns correct error messages.
>>>  -  We can use swagger-codegen to do this.
>>>  API Definition has all the details of the API interface what
>>> missing are
>>>
>>> 2. How to get the existing integration test to utilize the new API.
>>>  - We already have a lot of integration tests which uses
>>> existing store & publisher APIs to add/remove resources. As Saneth 
>>> mention
>>> they have written it in a layered architecture this replacing the 
>>> existing
>>> API layer with Jax-rs existing test should work.
>>>
>>>
>>> 3. How to make it easy to write test in the future with Jax-Rs API.
>>>
>>>
>>>
>>>
>>> On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda <
>>> sanje...@wso2.com> wrote:
>>>
 Hi Team,
 We are planning to implement complete REST API for all operations
 available in API Manager.
 This will be CXF based jax-rs application.
 This application based on swagger template and service skeleton
 automatically generate according to swagger to cxf implementation 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Sanjeewa Malalgoda]

QAA team shall we have discussion on this and come to conclusion?
Please let us know possible time slots.

Thanks,
sanjeewa.

On Mon, Oct 19, 2015 at 12:44 PM, Sanjeewa Malalgoda 
wrote:

> Here idea is easily manage the tests and web application.
> Since web application purely depend on swagger definition it will
> automatically generate beans, service skeletons etc.
>
> So in same way if we implement test cases we don't have to go and edit
> test case code after we adding new parameters or something like that.
> What we can simply do is change sample data set feed into test.
>
>
>
> On Mon, Oct 19, 2015 at 12:34 PM, Joseph Fonseka  wrote:
>
>> Hi Nuwan
>>
>> Thanks for pointing that out, in that case test can be version-ed so auto
>> generated tests for version 1.0.0 should work with API 1.0.1 ...
>>
>> WDYT?
>>
>> Regards
>> Jo
>>
>> On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias  wrote:
>>
>>> Is it right to auto-generate the test client code? IMO one objective of
>>> this should be to make sure the REST APIs don't change across patch
>>> releases, etc. If we auto-generate the test stubs we would loose that
>>> advantage.
>>>
>> I don't get how we loose advantage here.
> If we don't want to change service API we don't have to edit swagger json
> and that is it.
> Then it will not change service API, neither test client or data set feed
> in to test.
> If we consider both integration and unit tests those will be released
> anyway with product and component release.
> So tests will be automatically version-ed with component/product version.
>
> Thanks,
> sanjeewa.
>
>
>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka 
>>> wrote:
>>>
 Hi Sanjeewa

 Saneth & I had an offline chat regarding this last week there are few
 things we need to consider.

 1. Generating integration test for the Jax-RS functionality ex . If
 crud operations work, if it returns correct error messages.
  -  We can use swagger-codegen to do this.
  -  API Definition has all the details of the API interface
 what missing are the data fixtures.
  - There are few options with the fixtures which we can auto
 generate since the schema of the model is there or we can use a predefined
 set of json files.

 2. How to get the existing integration test to utilize the new API.
  - We already have a lot of integration tests which uses
 existing store & publisher APIs to add/remove resources. As Saneth mention
 they have written it in a layered architecture this replacing the existing
 API layer with Jax-rs existing test should work.
  - We might have to look at this in the next phase when we plan
 to deprecate the existing APIs.

 3. How to make it easy to write test in the future with Jax-Rs API.
  - Ex Creating a Jax-rs client/library to utilize by other
 integration test.

 Thanks & Regards
 Jo

 On Mon, Oct 19, 2015 at 12:17 PM, Joseph Fonseka 
 wrote:

> Sorry mail got sent accidentally half written. will complete and send
> shortly.
>
> On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka 
> wrote:
>
>> Hi Sanjeewa
>>
>> Saneth & I had an offline chat regarding this last week there are few
>> things we need to consider.
>>
>> 1. Generating integration test for the Jax-RS functionality ex . If
>> crud operations work, if it returns correct error messages.
>>  -  We can use swagger-codegen to do this.
>>  API Definition has all the details of the API interface what missing
>> are
>>
>> 2. How to get the existing integration test to utilize the new API.
>>  - We already have a lot of integration tests which uses
>> existing store & publisher APIs to add/remove resources. As Saneth 
>> mention
>> they have written it in a layered architecture this replacing the 
>> existing
>> API layer with Jax-rs existing test should work.
>>
>>
>> 3. How to make it easy to write test in the future with Jax-Rs API.
>>
>>
>>
>>
>> On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda <
>> sanje...@wso2.com> wrote:
>>
>>> Hi Team,
>>> We are planning to implement complete REST API for all operations
>>> available in API Manager.
>>> This will be CXF based jax-rs application.
>>> This application based on swagger template and service skeleton
>>> automatically generate according to swagger to cxf implementation done 
>>> by
>>> Jo.
>>> We would like to know what would be the best approach to implement
>>> test for this service.
>>> Do we have any mechanism to generate client and test service in unit
>>> test level ? I can see there are projects to generate java 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Joseph Fonseka]

Sorry mail got sent accidentally half written. will complete and send
shortly.

On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka  wrote:

> Hi Sanjeewa
>
> Saneth & I had an offline chat regarding this last week there are few
> things we need to consider.
>
> 1. Generating integration test for the Jax-RS functionality ex . If crud
> operations work, if it returns correct error messages.
>  -  We can use swagger-codegen to do this.
>  API Definition has all the details of the API interface what missing are
>
> 2. How to get the existing integration test to utilize the new API.
>  - We already have a lot of integration tests which uses existing
> store & publisher APIs to add/remove resources. As Saneth mention they have
> written it in a layered architecture this replacing the existing API layer
> with Jax-rs existing test should work.
>
>
> 3. How to make it easy to write test in the future with Jax-Rs API.
>
>
>
>
> On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi Team,
>> We are planning to implement complete REST API for all operations
>> available in API Manager.
>> This will be CXF based jax-rs application.
>> This application based on swagger template and service skeleton
>> automatically generate according to swagger to cxf implementation done by
>> Jo.
>> We would like to know what would be the best approach to implement test
>> for this service.
>> Do we have any mechanism to generate client and test service in unit test
>> level ? I can see there are projects to generate java client based on
>> swagger content.
>> Or do we need to write integration test to run this application in server
>> and perform tests?
>> Since this implementation changes rapidly it would be ideal if we can
>> have skeleton based testing approach without binding to real
>> implementation(like auto generated client).
>>
>> Have we done something similar?
>> What would be the best approach?
>>
>> Thanks,
>> sanjeewa.
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779
>>
>> blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> 
>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * *
>
>


-- 

-- 
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 772 512 430
skype: jpfonseka

* *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Nuwan Dias]

Is it right to auto-generate the test client code? IMO one objective of
this should be to make sure the REST APIs don't change across patch
releases, etc. If we auto-generate the test stubs we would loose that
advantage.

Thanks,
NuwanD.

On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka  wrote:

> Hi Sanjeewa
>
> Saneth & I had an offline chat regarding this last week there are few
> things we need to consider.
>
> 1. Generating integration test for the Jax-RS functionality ex . If crud
> operations work, if it returns correct error messages.
>  -  We can use swagger-codegen to do this.
>  -  API Definition has all the details of the API interface what
> missing are the data fixtures.
>  - There are few options with the fixtures which we can auto
> generate since the schema of the model is there or we can use a predefined
> set of json files.
>
> 2. How to get the existing integration test to utilize the new API.
>  - We already have a lot of integration tests which uses existing
> store & publisher APIs to add/remove resources. As Saneth mention they have
> written it in a layered architecture this replacing the existing API layer
> with Jax-rs existing test should work.
>  - We might have to look at this in the next phase when we plan to
> deprecate the existing APIs.
>
> 3. How to make it easy to write test in the future with Jax-Rs API.
>  - Ex Creating a Jax-rs client/library to utilize by other
> integration test.
>
> Thanks & Regards
> Jo
>
> On Mon, Oct 19, 2015 at 12:17 PM, Joseph Fonseka  wrote:
>
>> Sorry mail got sent accidentally half written. will complete and send
>> shortly.
>>
>> On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka  wrote:
>>
>>> Hi Sanjeewa
>>>
>>> Saneth & I had an offline chat regarding this last week there are few
>>> things we need to consider.
>>>
>>> 1. Generating integration test for the Jax-RS functionality ex . If crud
>>> operations work, if it returns correct error messages.
>>>  -  We can use swagger-codegen to do this.
>>>  API Definition has all the details of the API interface what missing
>>> are
>>>
>>> 2. How to get the existing integration test to utilize the new API.
>>>  - We already have a lot of integration tests which uses
>>> existing store & publisher APIs to add/remove resources. As Saneth mention
>>> they have written it in a layered architecture this replacing the existing
>>> API layer with Jax-rs existing test should work.
>>>
>>>
>>> 3. How to make it easy to write test in the future with Jax-Rs API.
>>>
>>>
>>>
>>>
>>> On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda 
>>> wrote:
>>>
 Hi Team,
 We are planning to implement complete REST API for all operations
 available in API Manager.
 This will be CXF based jax-rs application.
 This application based on swagger template and service skeleton
 automatically generate according to swagger to cxf implementation done by
 Jo.
 We would like to know what would be the best approach to implement test
 for this service.
 Do we have any mechanism to generate client and test service in unit
 test level ? I can see there are projects to generate java client based on
 swagger content.
 Or do we need to write integration test to run this application in
 server and perform tests?
 Since this implementation changes rapidly it would be ideal if we can
 have skeleton based testing approach without binding to real
 implementation(like auto generated client).

 Have we done something similar?
 What would be the best approach?

 Thanks,
 sanjeewa.

 --

 *Sanjeewa Malalgoda*
 WSO2 Inc.
 Mobile : +94713068779

 blog
 :http://sanjeewamalalgoda.blogspot.com/
 



 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>>
>>> --
>>> *Joseph Fonseka*
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 772 512 430
>>> skype: jpfonseka
>>>
>>> * *
>>>
>>>
>>
>>
>> --
>>
>> --
>> *Joseph Fonseka*
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 772 512 430
>> skype: jpfonseka
>>
>> * *
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * *
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Nuwan Dias

Technical Lead - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 

[Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Sanjeewa Malalgoda]

Hi Team,
We are planning to implement complete REST API for all operations available
in API Manager.
This will be CXF based jax-rs application.
This application based on swagger template and service skeleton
automatically generate according to swagger to cxf implementation done by
Jo.
We would like to know what would be the best approach to implement test for
this service.
Do we have any mechanism to generate client and test service in unit test
level ? I can see there are projects to generate java client based on
swagger content.
Or do we need to write integration test to run this application in server
and perform tests?
Since this implementation changes rapidly it would be ideal if we can have
skeleton based testing approach without binding to real implementation(like
auto generated client).

Have we done something similar?
What would be the best approach?

Thanks,
sanjeewa.

-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

blog
:http://sanjeewamalalgoda.blogspot.com/

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Sanjeewa Malalgoda]

On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda 
wrote:

> Hi Team,
> We are planning to implement complete REST API for all operations
> available in API Manager.
> This will be CXF based jax-rs application.
> This application based on swagger template and service skeleton
> automatically generate according to swagger to cxf implementation done by
> Jo.
> We would like to know what would be the best approach to implement test
> for this service.
> Do we have any mechanism to generate client and test service in unit test
> level ? I can see there are projects to generate java client based on
> swagger content.
> Or do we need to write integration test to run this application in server
> and perform tests?
> Since this implementation changes rapidly it would be ideal if we can have
> skeleton based testing approach without binding to real implementation(like
> auto generated client).
>
> Have we done something similar?
> What would be the best approach?
>
> Thanks,
> sanjeewa.
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> blog
> :http://sanjeewamalalgoda.blogspot.com/
> 
>
>
>


-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

blog
:http://sanjeewamalalgoda.blogspot.com/

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Joseph Fonseka]

Hi Sanjeewa

Saneth & I had an offline chat regarding this last week there are few
things we need to consider.

1. Generating integration test for the Jax-RS functionality ex . If crud
operations work, if it returns correct error messages.
 -  We can use swagger-codegen to do this.
 API Definition has all the details of the API interface what missing are

2. How to get the existing integration test to utilize the new API.
 - We already have a lot of integration tests which uses existing
store & publisher APIs to add/remove resources. As Saneth mention they have
written it in a layered architecture this replacing the existing API layer
with Jax-rs existing test should work.


3. How to make it easy to write test in the future with Jax-Rs API.




On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda 
wrote:

> Hi Team,
> We are planning to implement complete REST API for all operations
> available in API Manager.
> This will be CXF based jax-rs application.
> This application based on swagger template and service skeleton
> automatically generate according to swagger to cxf implementation done by
> Jo.
> We would like to know what would be the best approach to implement test
> for this service.
> Do we have any mechanism to generate client and test service in unit test
> level ? I can see there are projects to generate java client based on
> swagger content.
> Or do we need to write integration test to run this application in server
> and perform tests?
> Since this implementation changes rapidly it would be ideal if we can have
> skeleton based testing approach without binding to real implementation(like
> auto generated client).
>
> Have we done something similar?
> What would be the best approach?
>
> Thanks,
> sanjeewa.
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> blog
> :http://sanjeewamalalgoda.blogspot.com/
> 
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 

-- 
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 772 512 430
skype: jpfonseka

* *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Dharshana Warusavitharana]

Hi Sanjeewa,

Currently we are not using a mechanism to proceed testing with auto
generated clients. As I understand by the requirement this might subject to
change API definition posted by the application with changes in the product
level.

But as per the requirement I think it would be ideal if we can follow an
approach to add both unit tests and integration tests for the scenario.

Currently we are using simple CXF application to monitor API and Sample
applications used by integration tests to verify its  state of deployment.
In this case we just deploy the webapp and invoke it inside test methods.
Which is bit similar to what you are doing here. In this we deploy
out cxf application in APIM itself. So in your case also we do not need
additional application container to move on.

As I see we can follow same approach we are doing with service stubs. In
build time we can generate client using WADL -> Java or swagger ->  java
approach and use it inside tests. This will illuminate effort in redoing
all tests while API definition is changed.

Thank you,
Dharshana.


On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka  wrote:

> Hi Sanjeewa
>
> Saneth & I had an offline chat regarding this last week there are few
> things we need to consider.
>
> 1. Generating integration test for the Jax-RS functionality ex . If crud
> operations work, if it returns correct error messages.
>  -  We can use swagger-codegen to do this.
>  API Definition has all the details of the API interface what missing are
>
> 2. How to get the existing integration test to utilize the new API.
>  - We already have a lot of integration tests which uses existing
> store & publisher APIs to add/remove resources. As Saneth mention they have
> written it in a layered architecture this replacing the existing API layer
> with Jax-rs existing test should work.
>
>
> 3. How to make it easy to write test in the future with Jax-Rs API.
>
>
>
>
> On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi Team,
>> We are planning to implement complete REST API for all operations
>> available in API Manager.
>> This will be CXF based jax-rs application.
>> This application based on swagger template and service skeleton
>> automatically generate according to swagger to cxf implementation done by
>> Jo.
>> We would like to know what would be the best approach to implement test
>> for this service.
>> Do we have any mechanism to generate client and test service in unit test
>> level ? I can see there are projects to generate java client based on
>> swagger content.
>> Or do we need to write integration test to run this application in server
>> and perform tests?
>> Since this implementation changes rapidly it would be ideal if we can
>> have skeleton based testing approach without binding to real
>> implementation(like auto generated client).
>>
>> Have we done something similar?
>> What would be the best approach?
>>
>> Thanks,
>> sanjeewa.
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779
>>
>> blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> 
>>
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * *
>
>


-- 

Dharshana Warusavitharana
Senior Software Engineer , Test Automation
WSO2 Inc. http://wso2.com
email : dharsha...@wso2.com 
Tel  : +94 11 214 5345
Fax :+94 11 2145300
cell : +94770342233
blog : http://dharshanaw.blogspot.com

lean . enterprise . middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Joseph Fonseka]

Hi Sanjeewa

Saneth & I had an offline chat regarding this last week there are few
things we need to consider.

1. Generating integration test for the Jax-RS functionality ex . If crud
operations work, if it returns correct error messages.
 -  We can use swagger-codegen to do this.
 -  API Definition has all the details of the API interface what
missing are the data fixtures.
 - There are few options with the fixtures which we can auto
generate since the schema of the model is there or we can use a predefined
set of json files.

2. How to get the existing integration test to utilize the new API.
 - We already have a lot of integration tests which uses existing
store & publisher APIs to add/remove resources. As Saneth mention they have
written it in a layered architecture this replacing the existing API layer
with Jax-rs existing test should work.
 - We might have to look at this in the next phase when we plan to
deprecate the existing APIs.

3. How to make it easy to write test in the future with Jax-Rs API.
 - Ex Creating a Jax-rs client/library to utilize by other
integration test.

Thanks & Regards
Jo

On Mon, Oct 19, 2015 at 12:17 PM, Joseph Fonseka  wrote:

> Sorry mail got sent accidentally half written. will complete and send
> shortly.
>
> On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka  wrote:
>
>> Hi Sanjeewa
>>
>> Saneth & I had an offline chat regarding this last week there are few
>> things we need to consider.
>>
>> 1. Generating integration test for the Jax-RS functionality ex . If crud
>> operations work, if it returns correct error messages.
>>  -  We can use swagger-codegen to do this.
>>  API Definition has all the details of the API interface what missing are
>>
>> 2. How to get the existing integration test to utilize the new API.
>>  - We already have a lot of integration tests which uses existing
>> store & publisher APIs to add/remove resources. As Saneth mention they have
>> written it in a layered architecture this replacing the existing API layer
>> with Jax-rs existing test should work.
>>
>>
>> 3. How to make it easy to write test in the future with Jax-Rs API.
>>
>>
>>
>>
>> On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> Hi Team,
>>> We are planning to implement complete REST API for all operations
>>> available in API Manager.
>>> This will be CXF based jax-rs application.
>>> This application based on swagger template and service skeleton
>>> automatically generate according to swagger to cxf implementation done by
>>> Jo.
>>> We would like to know what would be the best approach to implement test
>>> for this service.
>>> Do we have any mechanism to generate client and test service in unit
>>> test level ? I can see there are projects to generate java client based on
>>> swagger content.
>>> Or do we need to write integration test to run this application in
>>> server and perform tests?
>>> Since this implementation changes rapidly it would be ideal if we can
>>> have skeleton based testing approach without binding to real
>>> implementation(like auto generated client).
>>>
>>> Have we done something similar?
>>> What would be the best approach?
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779
>>>
>>> blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>> --
>> *Joseph Fonseka*
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 772 512 430
>> skype: jpfonseka
>>
>> * *
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * *
>
>


-- 

-- 
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 772 512 430
skype: jpfonseka

* *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Joseph Fonseka]

Hi Nuwan

Thanks for pointing that out, in that case test can be version-ed so auto
generated tests for version 1.0.0 should work with API 1.0.1 ...

WDYT?

Regards
Jo

On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias  wrote:

> Is it right to auto-generate the test client code? IMO one objective of
> this should be to make sure the REST APIs don't change across patch
> releases, etc. If we auto-generate the test stubs we would loose that
> advantage.
>
> Thanks,
> NuwanD.
>
> On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka  wrote:
>
>> Hi Sanjeewa
>>
>> Saneth & I had an offline chat regarding this last week there are few
>> things we need to consider.
>>
>> 1. Generating integration test for the Jax-RS functionality ex . If crud
>> operations work, if it returns correct error messages.
>>  -  We can use swagger-codegen to do this.
>>  -  API Definition has all the details of the API interface what
>> missing are the data fixtures.
>>  - There are few options with the fixtures which we can auto
>> generate since the schema of the model is there or we can use a predefined
>> set of json files.
>>
>> 2. How to get the existing integration test to utilize the new API.
>>  - We already have a lot of integration tests which uses existing
>> store & publisher APIs to add/remove resources. As Saneth mention they have
>> written it in a layered architecture this replacing the existing API layer
>> with Jax-rs existing test should work.
>>  - We might have to look at this in the next phase when we plan
>> to deprecate the existing APIs.
>>
>> 3. How to make it easy to write test in the future with Jax-Rs API.
>>  - Ex Creating a Jax-rs client/library to utilize by other
>> integration test.
>>
>> Thanks & Regards
>> Jo
>>
>> On Mon, Oct 19, 2015 at 12:17 PM, Joseph Fonseka  wrote:
>>
>>> Sorry mail got sent accidentally half written. will complete and send
>>> shortly.
>>>
>>> On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka 
>>> wrote:
>>>
 Hi Sanjeewa

 Saneth & I had an offline chat regarding this last week there are few
 things we need to consider.

 1. Generating integration test for the Jax-RS functionality ex . If
 crud operations work, if it returns correct error messages.
  -  We can use swagger-codegen to do this.
  API Definition has all the details of the API interface what missing
 are

 2. How to get the existing integration test to utilize the new API.
  - We already have a lot of integration tests which uses
 existing store & publisher APIs to add/remove resources. As Saneth mention
 they have written it in a layered architecture this replacing the existing
 API layer with Jax-rs existing test should work.


 3. How to make it easy to write test in the future with Jax-Rs API.




 On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda  wrote:

> Hi Team,
> We are planning to implement complete REST API for all operations
> available in API Manager.
> This will be CXF based jax-rs application.
> This application based on swagger template and service skeleton
> automatically generate according to swagger to cxf implementation done by
> Jo.
> We would like to know what would be the best approach to implement
> test for this service.
> Do we have any mechanism to generate client and test service in unit
> test level ? I can see there are projects to generate java client based on
> swagger content.
> Or do we need to write integration test to run this application in
> server and perform tests?
> Since this implementation changes rapidly it would be ideal if we can
> have skeleton based testing approach without binding to real
> implementation(like auto generated client).
>
> Have we done something similar?
> What would be the best approach?
>
> Thanks,
> sanjeewa.
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> blog
> :http://sanjeewamalalgoda.blogspot.com/
> 
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --

 --
 *Joseph Fonseka*
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * *


>>>
>>>
>>> --
>>>
>>> --
>>> *Joseph Fonseka*
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 772 512 430
>>> skype: jpfonseka
>>>
>>> * *
>>>
>>>
>>
>>
>> --
>>
>> --
>> *Joseph 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Dharshana Warusavitharana]

Hi Jo,

If so the issue is how you eliminate the client generation on normal
product build. So if there is a requirement of maintaining API as it is it
is a bad idea it generate test client on demand.
So in bottom line you only expect API change for 1.0.0 in next main release
2.0.0. So this won't be a issue to refine clients when it comes to major
release.

You can mountain all API definitions on a single place referring base class
method. So changes would be minimal when you do a major release with API
change.

Thank you,
Dharshana.

On Mon, Oct 19, 2015 at 12:34 PM, Joseph Fonseka  wrote:

> Hi Nuwan
>
> Thanks for pointing that out, in that case test can be version-ed so auto
> generated tests for version 1.0.0 should work with API 1.0.1 ...
>
> WDYT?
>
> Regards
> Jo
>
> On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias  wrote:
>
>> Is it right to auto-generate the test client code? IMO one objective of
>> this should be to make sure the REST APIs don't change across patch
>> releases, etc. If we auto-generate the test stubs we would loose that
>> advantage.
>>
>> Thanks,
>> NuwanD.
>>
>> On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka  wrote:
>>
>>> Hi Sanjeewa
>>>
>>> Saneth & I had an offline chat regarding this last week there are few
>>> things we need to consider.
>>>
>>> 1. Generating integration test for the Jax-RS functionality ex . If crud
>>> operations work, if it returns correct error messages.
>>>  -  We can use swagger-codegen to do this.
>>>  -  API Definition has all the details of the API interface what
>>> missing are the data fixtures.
>>>  - There are few options with the fixtures which we can auto
>>> generate since the schema of the model is there or we can use a predefined
>>> set of json files.
>>>
>>> 2. How to get the existing integration test to utilize the new API.
>>>  - We already have a lot of integration tests which uses
>>> existing store & publisher APIs to add/remove resources. As Saneth mention
>>> they have written it in a layered architecture this replacing the existing
>>> API layer with Jax-rs existing test should work.
>>>  - We might have to look at this in the next phase when we plan
>>> to deprecate the existing APIs.
>>>
>>> 3. How to make it easy to write test in the future with Jax-Rs API.
>>>  - Ex Creating a Jax-rs client/library to utilize by other
>>> integration test.
>>>
>>> Thanks & Regards
>>> Jo
>>>
>>> On Mon, Oct 19, 2015 at 12:17 PM, Joseph Fonseka 
>>> wrote:
>>>
 Sorry mail got sent accidentally half written. will complete and send
 shortly.

 On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka 
 wrote:

> Hi Sanjeewa
>
> Saneth & I had an offline chat regarding this last week there are few
> things we need to consider.
>
> 1. Generating integration test for the Jax-RS functionality ex . If
> crud operations work, if it returns correct error messages.
>  -  We can use swagger-codegen to do this.
>  API Definition has all the details of the API interface what missing
> are
>
> 2. How to get the existing integration test to utilize the new API.
>  - We already have a lot of integration tests which uses
> existing store & publisher APIs to add/remove resources. As Saneth mention
> they have written it in a layered architecture this replacing the existing
> API layer with Jax-rs existing test should work.
>
>
> 3. How to make it easy to write test in the future with Jax-Rs API.
>
>
>
>
> On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda <
> sanje...@wso2.com> wrote:
>
>> Hi Team,
>> We are planning to implement complete REST API for all operations
>> available in API Manager.
>> This will be CXF based jax-rs application.
>> This application based on swagger template and service skeleton
>> automatically generate according to swagger to cxf implementation done by
>> Jo.
>> We would like to know what would be the best approach to implement
>> test for this service.
>> Do we have any mechanism to generate client and test service in unit
>> test level ? I can see there are projects to generate java client based 
>> on
>> swagger content.
>> Or do we need to write integration test to run this application in
>> server and perform tests?
>> Since this implementation changes rapidly it would be ideal if we can
>> have skeleton based testing approach without binding to real
>> implementation(like auto generated client).
>>
>> Have we done something similar?
>> What would be the best approach?
>>
>> Thanks,
>> sanjeewa.
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779
>>
>> blog
>> 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Sanjeewa Malalgoda]

Here idea is easily manage the tests and web application.
Since web application purely depend on swagger definition it will
automatically generate beans, service skeletons etc.

So in same way if we implement test cases we don't have to go and edit test
case code after we adding new parameters or something like that.
What we can simply do is change sample data set feed into test.



On Mon, Oct 19, 2015 at 12:34 PM, Joseph Fonseka  wrote:

> Hi Nuwan
>
> Thanks for pointing that out, in that case test can be version-ed so auto
> generated tests for version 1.0.0 should work with API 1.0.1 ...
>
> WDYT?
>
> Regards
> Jo
>
> On Mon, Oct 19, 2015 at 12:29 PM, Nuwan Dias  wrote:
>
>> Is it right to auto-generate the test client code? IMO one objective of
>> this should be to make sure the REST APIs don't change across patch
>> releases, etc. If we auto-generate the test stubs we would loose that
>> advantage.
>>
> I don't get how we loose advantage here.
If we don't want to change service API we don't have to edit swagger json
and that is it.
Then it will not change service API, neither test client or data set feed
in to test.
If we consider both integration and unit tests those will be released
anyway with product and component release.
So tests will be automatically version-ed with component/product version.

Thanks,
sanjeewa.


>
>> Thanks,
>> NuwanD.
>>
>> On Mon, Oct 19, 2015 at 12:26 PM, Joseph Fonseka  wrote:
>>
>>> Hi Sanjeewa
>>>
>>> Saneth & I had an offline chat regarding this last week there are few
>>> things we need to consider.
>>>
>>> 1. Generating integration test for the Jax-RS functionality ex . If crud
>>> operations work, if it returns correct error messages.
>>>  -  We can use swagger-codegen to do this.
>>>  -  API Definition has all the details of the API interface what
>>> missing are the data fixtures.
>>>  - There are few options with the fixtures which we can auto
>>> generate since the schema of the model is there or we can use a predefined
>>> set of json files.
>>>
>>> 2. How to get the existing integration test to utilize the new API.
>>>  - We already have a lot of integration tests which uses
>>> existing store & publisher APIs to add/remove resources. As Saneth mention
>>> they have written it in a layered architecture this replacing the existing
>>> API layer with Jax-rs existing test should work.
>>>  - We might have to look at this in the next phase when we plan
>>> to deprecate the existing APIs.
>>>
>>> 3. How to make it easy to write test in the future with Jax-Rs API.
>>>  - Ex Creating a Jax-rs client/library to utilize by other
>>> integration test.
>>>
>>> Thanks & Regards
>>> Jo
>>>
>>> On Mon, Oct 19, 2015 at 12:17 PM, Joseph Fonseka 
>>> wrote:
>>>
 Sorry mail got sent accidentally half written. will complete and send
 shortly.

 On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka 
 wrote:

> Hi Sanjeewa
>
> Saneth & I had an offline chat regarding this last week there are few
> things we need to consider.
>
> 1. Generating integration test for the Jax-RS functionality ex . If
> crud operations work, if it returns correct error messages.
>  -  We can use swagger-codegen to do this.
>  API Definition has all the details of the API interface what missing
> are
>
> 2. How to get the existing integration test to utilize the new API.
>  - We already have a lot of integration tests which uses
> existing store & publisher APIs to add/remove resources. As Saneth mention
> they have written it in a layered architecture this replacing the existing
> API layer with Jax-rs existing test should work.
>
>
> 3. How to make it easy to write test in the future with Jax-Rs API.
>
>
>
>
> On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda <
> sanje...@wso2.com> wrote:
>
>> Hi Team,
>> We are planning to implement complete REST API for all operations
>> available in API Manager.
>> This will be CXF based jax-rs application.
>> This application based on swagger template and service skeleton
>> automatically generate according to swagger to cxf implementation done by
>> Jo.
>> We would like to know what would be the best approach to implement
>> test for this service.
>> Do we have any mechanism to generate client and test service in unit
>> test level ? I can see there are projects to generate java client based 
>> on
>> swagger content.
>> Or do we need to write integration test to run this application in
>> server and perform tests?
>> Since this implementation changes rapidly it would be ideal if we can
>> have skeleton based testing approach without binding to real
>> implementation(like auto generated client).
>>
>> Have we done 

Re: [Dev] [DEV] Implement unit/integration test cases for API Manager JAX-RS Rest API

[Dharshana Warusavitharana]

Hi Jo,

As per the practise we followed there won't be a big effort in migrating
these tests since we use base test methods to use these API calls. So we
can handle this without changing tests.

Thank you,
Dharshana.


On Mon, Oct 19, 2015 at 12:17 PM, Joseph Fonseka  wrote:

> Sorry mail got sent accidentally half written. will complete and send
> shortly.
>
> On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka  wrote:
>
>> Hi Sanjeewa
>>
>> Saneth & I had an offline chat regarding this last week there are few
>> things we need to consider.
>>
>> 1. Generating integration test for the Jax-RS functionality ex . If crud
>> operations work, if it returns correct error messages.
>>  -  We can use swagger-codegen to do this.
>>  API Definition has all the details of the API interface what missing are
>>
>> 2. How to get the existing integration test to utilize the new API.
>>  - We already have a lot of integration tests which uses existing
>> store & publisher APIs to add/remove resources. As Saneth mention they have
>> written it in a layered architecture this replacing the existing API layer
>> with Jax-rs existing test should work.
>>
>>
>> 3. How to make it easy to write test in the future with Jax-Rs API.
>>
>>
>>
>>
>> On Mon, Oct 19, 2015 at 11:39 AM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> Hi Team,
>>> We are planning to implement complete REST API for all operations
>>> available in API Manager.
>>> This will be CXF based jax-rs application.
>>> This application based on swagger template and service skeleton
>>> automatically generate according to swagger to cxf implementation done by
>>> Jo.
>>> We would like to know what would be the best approach to implement test
>>> for this service.
>>> Do we have any mechanism to generate client and test service in unit
>>> test level ? I can see there are projects to generate java client based on
>>> swagger content.
>>> Or do we need to write integration test to run this application in
>>> server and perform tests?
>>> Since this implementation changes rapidly it would be ideal if we can
>>> have skeleton based testing approach without binding to real
>>> implementation(like auto generated client).
>>>
>>> Have we done something similar?
>>> What would be the best approach?
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779
>>>
>>> blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>> --
>> *Joseph Fonseka*
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 772 512 430
>> skype: jpfonseka
>>
>> * *
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * *
>
>


-- 

Dharshana Warusavitharana
Senior Software Engineer , Test Automation
WSO2 Inc. http://wso2.com
email : dharsha...@wso2.com 
Tel  : +94 11 214 5345
Fax :+94 11 2145300
cell : +94770342233
blog : http://dharshanaw.blogspot.com

lean . enterprise . middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev