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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>> wrote:
>>>
>>>> Sorry mail got sent accidentally half written. will complete and send
>>>> shortly.
>>>>
>>>> On Mon, Oct 19, 2015 at 12:15 PM, Joseph Fonseka <[email protected]>
>>>> 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 <
>>>>> [email protected]> 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
>>>>>>
>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> [email protected]
>>>>>> 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
>>>>>
>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> --
>>>> *Joseph Fonseka*
>>>> WSO2 Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> mobile: +94 772 512 430
>>>> skype: jpfonseka
>>>>
>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> --
>>> *Joseph Fonseka*
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 772 512 430
>>> skype: jpfonseka
>>>
>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [email protected]
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Technical Lead - WSO2, Inc. http://wso2.com
>> email : [email protected]
>> Phone : +94 777 775 729
>>
>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * <http://lk.linkedin.com/in/rumeshbandara>*
>
>
> _______________________________________________
> Dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 

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

lean . enterprise . middleware
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to