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
+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 codin
Hi Malintha,
Initially, we got the data driven test framework from the APIM code base.
When we were writing the test based on the data driven util framework I
found some limitation as below.
1. We can't test the body-asserts[1] using the framework.
2. We can't do a POST method with the payload as
Hi Sanjeewa,
Thanks for the reply. Yes, with the new data driven test module, tests can
be written fast and simple manner. Looks like there are many test cases we
can convert to use the data driven module. May be we can go through the
existing test cases and mark which of them can be converted to
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
Hi Sajith,
Thanks for the feedback. We did some recent changes to data driven module
to support body asserts using jsonpath/regex pairs. Please have a look at
[1].
We should add multi part form data support as well. That is essential in
testing REST API operations like thumbnail uploads. Thanks fo
On Fri, Aug 19, 2016 at 12:09 PM, Malintha Amarasinghe
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-c
Hi,
On Fri, Aug 19, 2016 at 12:09 PM, Malintha Amarasinghe
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/te
Hi Praminda
How was the "authorizationUrl/tokenUrl" set to the security definitions was
it hardcoded or does it dynamically resolve the URL based on the setup. Let
say if we want to test a distributed deployment does it pick tokenUrl may
be from configs.
Thanks
Jo
On Mon, Aug 22, 2016 at 10:34 A
Hi Jo,
I used a hardcoded dummy URL for the tokenUrl.
In an offline discussion with Nuwan and Malintha we decided to have a
separate Util class to handle the OAuth flow. Test case developer can use
this Util class to create the OAuth app and generate the access token. Then
that access token can b
How about having the OAuth flow transparent to the test case developer ?
which will require one less step when writing a test case.
We can achieve above by creating a Factory to get the Client with a token.
The Factory will deal with token generation probably talking to endpoints
in the configs. S
+1 to what Jo suggested, I have written some classes to already do this but
haven't committed the code. @Malintha and Praminda, you can reuse these if
you wish.
On 29 August 2016 at 12:00, Joseph Fonseka wrote:
> How about having the OAuth flow transparent to the test case developer ?
> which wi
12 matches
Mail list logo
