Hi,
We have completed implementing this common class and we will commit this to
GIT soon. Instead writing any java test class extending this common class
we can simply add the test class to the testng.xml inside the
[PRODUCT_HOME]/modules/integration/tests-integration/xxx/src/test/resources
direct
Hi Chamil
On Thu, Jul 10, 2014 at 12:39 PM, Chamil Jeewantha wrote:
> Hi All,
>
> I was thinking the tests are written in Java. I had a chat with Ruchira &
> understood the tests are written in Jaggery. So let me take back the
> annotation. BTW, my personal opinion is, just putting a dummy java
Hi Ruchira,
On Thu, Jul 10, 2014 at 12:10 PM, Ruchira Wageesha wrote:
> Hi Krishantha,
>
> If it is just a dummy class as you mentioned, then that would be fine.
> i.e. we neither need to maintain any *.xml configurations or Java codes,
> other than the pom.xml configuration.
>
> Regarding my in
Hi Chamil,
On Thu, Jul 10, 2014 at 10:57 AM, Chamil Jeewantha wrote:
> AFAIU, If any test is extended from the base class, you identify it as a
> jaggery test and do some special treatment like integrating to Emma etc...
> The annotation marks the class as qualified to receive the special
> trea
Hi All,
I was thinking the tests are written in Java. I had a chat with Ruchira &
understood the tests are written in Jaggery. So let me take back the
annotation. BTW, my personal opinion is, just putting a dummy java class to
identify whether its Jaggery test is bit odd.
There are many other jav
Hi Krishantha,
If it is just a dummy class as you mentioned, then that would be fine. i.e.
we neither need to maintain any *.xml configurations or Java codes, other
than the pom.xml configuration.
Regarding my initial suggestion, you would be able to do it using [1].
[1]
http://testng.org/doc/do
AFAIU, If any test is extended from the base class, you identify it as a
jaggery test and do some special treatment like integrating to Emma etc...
The annotation marks the class as qualified to receive the special
treatment you are going to do within the abstract class. The best example
is the dif
+1. IMO we do not need to introduce any customs annotations here. We
already have common tests like OSGIServerBundleStatusTest etc. written in
the same way.
On Thu, Jul 10, 2014 at 10:25 AM, Krishantha Samaraweera <
krishan...@wso2.com> wrote:
> Hi Chamil,
>
> We can introduce TestNG custom ann
Hi Chamil,
We can introduce TestNG custom annotation easily, but I'm in confusion how
custom annotation fit in to this context.
Only thing which comes to my mind is include the base class to all products
using TestNG annotation transform listener.
Thanks,
Krishantha.
On Thu, Jul 10, 2014 a
Hi All,
Why can't we use an annotation like @JaggeryTest rather than a Base class
in this case? It will be more sophisticated to the test writers.
Regards,
Chamil
On Wed, Jul 9, 2014 at 11:59 AM, Ruchira Wageesha wrote:
> Hi Krishantha,
>
> You should be able to use the same admin service tha
Hi Krishantha,
You should be able to use the same admin service that you use for Java
webapps.
On Wed, Jul 9, 2014 at 11:20 AM, Krishantha Samaraweera wrote:
> Hi Ruchira,
>
>
> On Mon, Jul 7, 2014 at 6:39 PM, Ruchira Wageesha wrote:
>
>>
>>
>>
>> On Mon, Jul 7, 2014 at 4:46 PM, Krishantha Sa
Hi Ruchira,
On Mon, Jul 7, 2014 at 6:39 PM, Ruchira Wageesha wrote:
>
>
>
> On Mon, Jul 7, 2014 at 4:46 PM, Krishantha Samaraweera <
> krishan...@wso2.com> wrote:
>
>> Hi Ruchira,
>>
>> This is not going to be a simple plugin to implement.This plugin will act
>> as a test executor and report ge
On Mon, Jul 7, 2014 at 4:46 PM, Krishantha Samaraweera
wrote:
> Hi Ruchira,
>
> This is not going to be a simple plugin to implement.This plugin will act
> as a test executor and report generator, and we need to integrate code
> coverage generation as well. Maven already provide sure-fire plug fo
Hi Ruchira,
This is not going to be a simple plugin to implement.This plugin will act
as a test executor and report generator, and we need to integrate code
coverage generation as well. Maven already provide sure-fire plug for test
execution and TestNG and Emma provide other capabilities. So writi
Hi Dimuthu,
With this approach, everyone who wants to test Jaggery apps will have to
write the same Java code by extending your base class, which is redundant.
Hence, IMO, the best options would be to wrap your base class and write a
maven plugin. So, what other's will have to do is, just add that
Hi,
I have started working on this. Our plan is to write a common test class
inside carbon-platform-integration-utils module which product teams can
extend and start running jaggery tests residing inside
[PRODUCT_HOME]/repository/deployment/server/jaggeryapps/xxx/test directory.
Invocation of each
16 matches
Mail list logo