Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Test and Performance Tools Platform (TPTP) » Post AGR recommendations?
Post AGR recommendations? [message #119357] Tue, 11 December 2007 13:02 Go to next message
Barbara Rosi-Schwartz is currently offline Barbara Rosi-SchwartzFriend
Messages: 448
Registered: July 2009
Senior Member
Hello everybody.

Following the effective demise of AGR as a tool for functional testing,
I am trying to come to grips with a possible alternative for our Eclipse
development effort.

Having read the inspiring article by David Black,
http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
I am exploring the possibility of moving away from the record/play back
paradigm and of using JUnit based tests for my functional testing. I
know that, in Eclipse, I have two options, namely the standard PDE JUnit
Plug-in tests and the TPTP JUnit Plug-in tests. However I am not really
familiar with either one and I find myself in the dark as to what
differences, pros and cons the two approaches have. If anybody has
reference material to point me to or any useful information, I would be
extremely grateful.

TIA,
B.

--
Barbara Rosi-Schwartz
Etish Limited [http://www.etish.org]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Post AGR recommendations? [message #119395 is a reply to message #119357] Wed, 12 December 2007 11:37 Go to previous messageGo to next message
Paul Slauenwhite is currently offline Paul SlauenwhiteFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Barbara,
I apologize for the inconvenience as a result of moving the AGR to
As-Is. Unfortunately, resources are limited and we must be responsive to
our contributing companies.

The TPTP JUnit/JUint Plug-in tests provide the same function as the PDE
JUnit/JUint Plug-in tests with the following added function:

-Graphical editor for editing the structure and behavior of JUnit/JUint
Plug-in test suites.
-API Recorder to record Java applications to create JUnit test suites.
-Remote test execution via the Agent Controller.
-Test Log and its viewer.
-Test execution reporting.

Paul
"Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in message
news:fjm1pc$5g4$1@build.eclipse.org...
> Hello everybody.
>
> Following the effective demise of AGR as a tool for functional testing, I
> am trying to come to grips with a possible alternative for our Eclipse
> development effort.
>
> Having read the inspiring article by David Black,
> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
> I am exploring the possibility of moving away from the record/play back
> paradigm and of using JUnit based tests for my functional testing. I know
> that, in Eclipse, I have two options, namely the standard PDE JUnit
> Plug-in tests and the TPTP JUnit Plug-in tests. However I am not really
> familiar with either one and I find myself in the dark as to what
> differences, pros and cons the two approaches have. If anybody has
> reference material to point me to or any useful information, I would be
> extremely grateful.
>
> TIA,
> B.
>
> --
> Barbara Rosi-Schwartz
> Etish Limited [http://www.etish.org]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ^...^
> / o,o \ The proud parents of Useme
> |) ::: (| The Open Requirements Management Tool
> ====w=w==== [https://useme.dev.java.net]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Post AGR recommendations? [message #119408 is a reply to message #119357] Wed, 12 December 2007 12:01 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: ffr.softwareag.com

Hi,

hm, hard to say, I'm not already over that point. It is not a fully
developed plan but currently I'm tending toward taking the AGR code, make it
independent from the TPTP platform and consider it as a self written testing
tool. Even if this would mean a not insignificant effort, it would open up
chances and new vistas. I'm a little unsatisfied with some of the TPTP
testing tool characteristics (the adoption of the UML2 testing profile for
example). Hence, I would adapt some things to my needs. For example the
structure of a test suite is too simple in my opinion. I'm missing test
scenarios (which can be nested) and the possibility for declaring
precondition and cleanup steps which not necessarily are automated GUI
actions. The AGR core, i.e. those parts of the software that perform the
recording and drive the replay, is good and stable enough for using further
on and worth to maintain.

Right at the moment I simply do nothing. Because I'm already running a more
or less heavily adapted private copy of AGR (which contains a number of
improvements, enhancements and bug fixes), I feel fit enough to come over
problems that arise sooner or later.

Regards

Frank

"Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in message
news:fjm1pc$5g4$1@build.eclipse.org...
> Hello everybody.
>
> Following the effective demise of AGR as a tool for functional testing, I
> am trying to come to grips with a possible alternative for our Eclipse
> development effort.
>
> Having read the inspiring article by David Black,
> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
> I am exploring the possibility of moving away from the record/play back
> paradigm and of using JUnit based tests for my functional testing. I know
> that, in Eclipse, I have two options, namely the standard PDE JUnit
> Plug-in tests and the TPTP JUnit Plug-in tests. However I am not really
> familiar with either one and I find myself in the dark as to what
> differences, pros and cons the two approaches have. If anybody has
> reference material to point me to or any useful information, I would be
> extremely grateful.
>
> TIA,
> B.
>
> --
> Barbara Rosi-Schwartz
> Etish Limited [http://www.etish.org]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ^...^
> / o,o \ The proud parents of Useme
> |) ::: (| The Open Requirements Management Tool
> ====w=w==== [https://useme.dev.java.net]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Post AGR recommendations? [message #119421 is a reply to message #119408] Wed, 12 December 2007 16:51 Go to previous messageGo to next message
Barbara Rosi-Schwartz is currently offline Barbara Rosi-SchwartzFriend
Messages: 448
Registered: July 2009
Senior Member
Frank,

Thank you for your insight. Your approach sounds interesting, but how
are you going to guard against incompatibilities of the AGR "core", as
you refer to it, with future versions of Eclipse?

Kindest regards,
B.

Barbara Rosi-Schwartz
Etish Limited [http://www.etish.org]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Frank Froehlich wrote:
> Hi,
>
> hm, hard to say, I'm not already over that point. It is not a fully
> developed plan but currently I'm tending toward taking the AGR code, make it
> independent from the TPTP platform and consider it as a self written testing
> tool. Even if this would mean a not insignificant effort, it would open up
> chances and new vistas. I'm a little unsatisfied with some of the TPTP
> testing tool characteristics (the adoption of the UML2 testing profile for
> example). Hence, I would adapt some things to my needs. For example the
> structure of a test suite is too simple in my opinion. I'm missing test
> scenarios (which can be nested) and the possibility for declaring
> precondition and cleanup steps which not necessarily are automated GUI
> actions. The AGR core, i.e. those parts of the software that perform the
> recording and drive the replay, is good and stable enough for using further
> on and worth to maintain.
>
> Right at the moment I simply do nothing. Because I'm already running a more
> or less heavily adapted private copy of AGR (which contains a number of
> improvements, enhancements and bug fixes), I feel fit enough to come over
> problems that arise sooner or later.
>
> Regards
>
> Frank
>
> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in message
> news:fjm1pc$5g4$1@build.eclipse.org...
>> Hello everybody.
>>
>> Following the effective demise of AGR as a tool for functional testing, I
>> am trying to come to grips with a possible alternative for our Eclipse
>> development effort.
>>
>> Having read the inspiring article by David Black,
>> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
>> I am exploring the possibility of moving away from the record/play back
>> paradigm and of using JUnit based tests for my functional testing. I know
>> that, in Eclipse, I have two options, namely the standard PDE JUnit
>> Plug-in tests and the TPTP JUnit Plug-in tests. However I am not really
>> familiar with either one and I find myself in the dark as to what
>> differences, pros and cons the two approaches have. If anybody has
>> reference material to point me to or any useful information, I would be
>> extremely grateful.
>>
>> TIA,
>> B.
>>
>> --
>> Barbara Rosi-Schwartz
>> Etish Limited [http://www.etish.org]
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ^...^
>> / o,o \ The proud parents of Useme
>> |) ::: (| The Open Requirements Management Tool
>> ====w=w==== [https://useme.dev.java.net]
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
Re: Post AGR recommendations? [message #119434 is a reply to message #119395] Wed, 12 December 2007 17:31 Go to previous messageGo to next message
Barbara Rosi-Schwartz is currently offline Barbara Rosi-SchwartzFriend
Messages: 448
Registered: July 2009
Senior Member
Thanks for your clear reply, Paul.

I have two questions:
1) does the API recorder only work for Java applications or for Eclipse
plug-ins as well?

2) are all of these (desirable) added features you list here to stay for
the foreseeable future or is there a risk that they are going to be
abandoned as was the case with AGR? Thanks.

Cheerio,
B.

Barbara Rosi-Schwartz
Etish Limited [http://www.etish.org]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Paul Slauenwhite wrote:
> Hi Barbara,
> I apologize for the inconvenience as a result of moving the AGR to
> As-Is. Unfortunately, resources are limited and we must be responsive to
> our contributing companies.
>
> The TPTP JUnit/JUint Plug-in tests provide the same function as the PDE
> JUnit/JUint Plug-in tests with the following added function:
>
> -Graphical editor for editing the structure and behavior of JUnit/JUint
> Plug-in test suites.
> -API Recorder to record Java applications to create JUnit test suites.
> -Remote test execution via the Agent Controller.
> -Test Log and its viewer.
> -Test execution reporting.
>
> Paul
> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in message
> news:fjm1pc$5g4$1@build.eclipse.org...
>> Hello everybody.
>>
>> Following the effective demise of AGR as a tool for functional testing, I
>> am trying to come to grips with a possible alternative for our Eclipse
>> development effort.
>>
>> Having read the inspiring article by David Black,
>> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
>> I am exploring the possibility of moving away from the record/play back
>> paradigm and of using JUnit based tests for my functional testing. I know
>> that, in Eclipse, I have two options, namely the standard PDE JUnit
>> Plug-in tests and the TPTP JUnit Plug-in tests. However I am not really
>> familiar with either one and I find myself in the dark as to what
>> differences, pros and cons the two approaches have. If anybody has
>> reference material to point me to or any useful information, I would be
>> extremely grateful.
>>
>> TIA,
>> B.
>>
>> --
>> Barbara Rosi-Schwartz
>> Etish Limited [http://www.etish.org]
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ^...^
>> / o,o \ The proud parents of Useme
>> |) ::: (| The Open Requirements Management Tool
>> ====w=w==== [https://useme.dev.java.net]
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
Re: Post AGR recommendations? [message #119447 is a reply to message #119421] Thu, 13 December 2007 10:33 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: ffr.softwareag.com

Hi Barbara,

the AGR core is pure SWT. The same level that David Black proposes to use
(good article btw, thanks). As long as the Eclipse GUI is SWT based the code
should work and should need just a small amount of maintenance effort. Once
you have a macro loaded (read from disk in whichever format) you can easily
feed at least the replay engine. Recording is a little bit more difficult
but manageable. The hard parts reside in different areas: 1. The heavy
dependency on the TPTP project framework (platform and testing). 2. The
close coupling with the UML2 testing profile 3. I currently don't know how
TPTPish the AutomationClientAdapter is and how to emulate the start of an
Eclipse instance with automated test execution - some research task for me.

Anyway, my vision is once having a Plug-in with minimum prereqs that allows
me to do the same things that AGR provides at the moment. Maybe stripping
down AGR could be a (the) key for performing automated GUI tests on RCP
applications too. It is a question of time (and knowledge, I know) to cope
with the task. At the moment I tend to tackle this task. I just need some
more days (or better: nights) to come to a decision.

Regards

Frank

"Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in message
news:fjp3ic$paq$2@build.eclipse.org...
> Frank,
>
> Thank you for your insight. Your approach sounds interesting, but how are
> you going to guard against incompatibilities of the AGR "core", as you
> refer to it, with future versions of Eclipse?
>
> Kindest regards,
> B.
>
> Barbara Rosi-Schwartz
> Etish Limited [http://www.etish.org]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ^...^
> / o,o \ The proud parents of Useme
> |) ::: (| The Open Requirements Management Tool
> ====w=w==== [https://useme.dev.java.net]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> Frank Froehlich wrote:
>> Hi,
>>
>> hm, hard to say, I'm not already over that point. It is not a fully
>> developed plan but currently I'm tending toward taking the AGR code, make
>> it independent from the TPTP platform and consider it as a self written
>> testing tool. Even if this would mean a not insignificant effort, it
>> would open up chances and new vistas. I'm a little unsatisfied with some
>> of the TPTP testing tool characteristics (the adoption of the UML2
>> testing profile for example). Hence, I would adapt some things to my
>> needs. For example the structure of a test suite is too simple in my
>> opinion. I'm missing test scenarios (which can be nested) and the
>> possibility for declaring precondition and cleanup steps which not
>> necessarily are automated GUI actions. The AGR core, i.e. those parts of
>> the software that perform the recording and drive the replay, is good and
>> stable enough for using further on and worth to maintain.
>>
>> Right at the moment I simply do nothing. Because I'm already running a
>> more or less heavily adapted private copy of AGR (which contains a number
>> of improvements, enhancements and bug fixes), I feel fit enough to come
>> over problems that arise sooner or later.
>>
>> Regards
>>
>> Frank
>>
>> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in
>> message news:fjm1pc$5g4$1@build.eclipse.org...
>>> Hello everybody.
>>>
>>> Following the effective demise of AGR as a tool for functional testing,
>>> I am trying to come to grips with a possible alternative for our Eclipse
>>> development effort.
>>>
>>> Having read the inspiring article by David Black,
>>> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
>>> I am exploring the possibility of moving away from the record/play back
>>> paradigm and of using JUnit based tests for my functional testing. I
>>> know that, in Eclipse, I have two options, namely the standard PDE JUnit
>>> Plug-in tests and the TPTP JUnit Plug-in tests. However I am not really
>>> familiar with either one and I find myself in the dark as to what
>>> differences, pros and cons the two approaches have. If anybody has
>>> reference material to point me to or any useful information, I would be
>>> extremely grateful.
>>>
>>> TIA,
>>> B.
>>>
>>> --
>>> Barbara Rosi-Schwartz
>>> Etish Limited [http://www.etish.org]
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> ^...^
>>> / o,o \ The proud parents of Useme
>>> |) ::: (| The Open Requirements Management Tool
>>> ====w=w==== [https://useme.dev.java.net]
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
Re: Post AGR recommendations? [message #119584 is a reply to message #119447] Sun, 16 December 2007 14:38 Go to previous messageGo to next message
Barbara Rosi-Schwartz is currently offline Barbara Rosi-SchwartzFriend
Messages: 448
Registered: July 2009
Senior Member
Frank,

Thank you very much for the detailed explanation. Sounds really good,
although it would be a little too time consuming (and beyond my current
level of understanding of the testing tools!...) for me to contemplate.

Good luck with it!

Tschuess,
B.

Barbara Rosi-Schwartz
Etish Limited [http://www.etish.org]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Frank Froehlich wrote:
> Hi Barbara,
>
> the AGR core is pure SWT. The same level that David Black proposes to use
> (good article btw, thanks). As long as the Eclipse GUI is SWT based the code
> should work and should need just a small amount of maintenance effort. Once
> you have a macro loaded (read from disk in whichever format) you can easily
> feed at least the replay engine. Recording is a little bit more difficult
> but manageable. The hard parts reside in different areas: 1. The heavy
> dependency on the TPTP project framework (platform and testing). 2. The
> close coupling with the UML2 testing profile 3. I currently don't know how
> TPTPish the AutomationClientAdapter is and how to emulate the start of an
> Eclipse instance with automated test execution - some research task for me.
>
> Anyway, my vision is once having a Plug-in with minimum prereqs that allows
> me to do the same things that AGR provides at the moment. Maybe stripping
> down AGR could be a (the) key for performing automated GUI tests on RCP
> applications too. It is a question of time (and knowledge, I know) to cope
> with the task. At the moment I tend to tackle this task. I just need some
> more days (or better: nights) to come to a decision.
>
> Regards
>
> Frank
>
> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in message
> news:fjp3ic$paq$2@build.eclipse.org...
>> Frank,
>>
>> Thank you for your insight. Your approach sounds interesting, but how are
>> you going to guard against incompatibilities of the AGR "core", as you
>> refer to it, with future versions of Eclipse?
>>
>> Kindest regards,
>> B.
>>
>> Barbara Rosi-Schwartz
>> Etish Limited [http://www.etish.org]
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ^...^
>> / o,o \ The proud parents of Useme
>> |) ::: (| The Open Requirements Management Tool
>> ====w=w==== [https://useme.dev.java.net]
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>> Frank Froehlich wrote:
>>> Hi,
>>>
>>> hm, hard to say, I'm not already over that point. It is not a fully
>>> developed plan but currently I'm tending toward taking the AGR code, make
>>> it independent from the TPTP platform and consider it as a self written
>>> testing tool. Even if this would mean a not insignificant effort, it
>>> would open up chances and new vistas. I'm a little unsatisfied with some
>>> of the TPTP testing tool characteristics (the adoption of the UML2
>>> testing profile for example). Hence, I would adapt some things to my
>>> needs. For example the structure of a test suite is too simple in my
>>> opinion. I'm missing test scenarios (which can be nested) and the
>>> possibility for declaring precondition and cleanup steps which not
>>> necessarily are automated GUI actions. The AGR core, i.e. those parts of
>>> the software that perform the recording and drive the replay, is good and
>>> stable enough for using further on and worth to maintain.
>>>
>>> Right at the moment I simply do nothing. Because I'm already running a
>>> more or less heavily adapted private copy of AGR (which contains a number
>>> of improvements, enhancements and bug fixes), I feel fit enough to come
>>> over problems that arise sooner or later.
>>>
>>> Regards
>>>
>>> Frank
>>>
>>> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in
>>> message news:fjm1pc$5g4$1@build.eclipse.org...
>>>> Hello everybody.
>>>>
>>>> Following the effective demise of AGR as a tool for functional testing,
>>>> I am trying to come to grips with a possible alternative for our Eclipse
>>>> development effort.
>>>>
>>>> Having read the inspiring article by David Black,
>>>> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
>>>> I am exploring the possibility of moving away from the record/play back
>>>> paradigm and of using JUnit based tests for my functional testing. I
>>>> know that, in Eclipse, I have two options, namely the standard PDE JUnit
>>>> Plug-in tests and the TPTP JUnit Plug-in tests. However I am not really
>>>> familiar with either one and I find myself in the dark as to what
>>>> differences, pros and cons the two approaches have. If anybody has
>>>> reference material to point me to or any useful information, I would be
>>>> extremely grateful.
>>>>
>>>> TIA,
>>>> B.
>>>>
>>>> --
>>>> Barbara Rosi-Schwartz
>>>> Etish Limited [http://www.etish.org]
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> ^...^
>>>> / o,o \ The proud parents of Useme
>>>> |) ::: (| The Open Requirements Management Tool
>>>> ====w=w==== [https://useme.dev.java.net]
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
Re: Post AGR recommendations? [message #119660 is a reply to message #119434] Mon, 17 December 2007 13:32 Go to previous messageGo to next message
Paul Slauenwhite is currently offline Paul SlauenwhiteFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Barbara,

1) Currently, only Java applications. Keep in mind that since this is a
Technology Preview, it is still under development and not as stable as our
GA level code.

2) Unfortunately, we reevaluate the staffing for the project at the
beginning of each major release (e.g. 4.6 in June 2008). During each review
phase, there is the potential of changes to the composition of the project.
That said, we have no plan at this time to change/remove these components in
4.5.

Paul
"Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in message
news:fjp5sr$dl5$2@build.eclipse.org...
> Thanks for your clear reply, Paul.
>
> I have two questions:
> 1) does the API recorder only work for Java applications or for Eclipse
> plug-ins as well?
>
> 2) are all of these (desirable) added features you list here to stay for
> the foreseeable future or is there a risk that they are going to be
> abandoned as was the case with AGR? Thanks.
>
> Cheerio,
> B.
>
> Barbara Rosi-Schwartz
> Etish Limited [http://www.etish.org]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ^...^
> / o,o \ The proud parents of Useme
> |) ::: (| The Open Requirements Management Tool
> ====w=w==== [https://useme.dev.java.net]
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> Paul Slauenwhite wrote:
>> Hi Barbara,
>> I apologize for the inconvenience as a result of moving the AGR to
>> As-Is. Unfortunately, resources are limited and we must be responsive to
>> our contributing companies.
>>
>> The TPTP JUnit/JUint Plug-in tests provide the same function as the
>> PDE JUnit/JUint Plug-in tests with the following added function:
>>
>> -Graphical editor for editing the structure and behavior of JUnit/JUint
>> Plug-in test suites.
>> -API Recorder to record Java applications to create JUnit test suites.
>> -Remote test execution via the Agent Controller.
>> -Test Log and its viewer.
>> -Test execution reporting.
>>
>> Paul
>> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in
>> message news:fjm1pc$5g4$1@build.eclipse.org...
>>> Hello everybody.
>>>
>>> Following the effective demise of AGR as a tool for functional testing,
>>> I am trying to come to grips with a possible alternative for our Eclipse
>>> development effort.
>>>
>>> Having read the inspiring article by David Black,
>>> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
>>> I am exploring the possibility of moving away from the record/play back
>>> paradigm and of using JUnit based tests for my functional testing. I
>>> know that, in Eclipse, I have two options, namely the standard PDE JUnit
>>> Plug-in tests and the TPTP JUnit Plug-in tests. However I am not really
>>> familiar with either one and I find myself in the dark as to what
>>> differences, pros and cons the two approaches have. If anybody has
>>> reference material to point me to or any useful information, I would be
>>> extremely grateful.
>>>
>>> TIA,
>>> B.
>>>
>>> --
>>> Barbara Rosi-Schwartz
>>> Etish Limited [http://www.etish.org]
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> ^...^
>>> / o,o \ The proud parents of Useme
>>> |) ::: (| The Open Requirements Management Tool
>>> ====w=w==== [https://useme.dev.java.net]
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
Re: Post AGR recommendations? [message #120626 is a reply to message #119447] Sun, 13 January 2008 16:50 Go to previous messageGo to next message
Jimmy Jin is currently offline Jimmy JinFriend
Messages: 32
Registered: July 2009
Member
Hi, Frank,

We have the same idea as yours to split the AGR core (playback engine)
out and create a standalone plug-in, so that we don't need to tight to
TPTP, especially when playback. Currently, we already partially did
that, except the dependency on the EMF model in TPTP and some other
models used by AGR for TestSuite, etc. Here just share with you our way
and maybe we can exchange ideas on this more. :-)

1. Create a new runner, so that the execution of testsuite can be
triggered without using Agent Controller. Now we can select a testsuite
file and run it in current Eclipse context successfully.
2. Removing all the recording GUI related classes. For some model
classes in TPTP used by AGR, just copy certain TPTP plug-in jar file
into the AGR plug-in and remove the external dependency. Since these are
just models, they have much less external dependencies further.
3. For EMF model dependencies, we are thinking about storing the
testsuite files as pure XML file, instead of EMF model file. Then the
dependency can be removed.

Regards,
Jimmy Jin

Frank Froehlich wrote:
> Hi Barbara,
>
> the AGR core is pure SWT. The same level that David Black proposes to use
> (good article btw, thanks). As long as the Eclipse GUI is SWT based the code
> should work and should need just a small amount of maintenance effort. Once
> you have a macro loaded (read from disk in whichever format) you can easily
> feed at least the replay engine. Recording is a little bit more difficult
> but manageable. The hard parts reside in different areas: 1. The heavy
> dependency on the TPTP project framework (platform and testing). 2. The
> close coupling with the UML2 testing profile 3. I currently don't know how
> TPTPish the AutomationClientAdapter is and how to emulate the start of an
> Eclipse instance with automated test execution - some research task for me.
>
> Anyway, my vision is once having a Plug-in with minimum prereqs that allows
> me to do the same things that AGR provides at the moment. Maybe stripping
> down AGR could be a (the) key for performing automated GUI tests on RCP
> applications too. It is a question of time (and knowledge, I know) to cope
> with the task. At the moment I tend to tackle this task. I just need some
> more days (or better: nights) to come to a decision.
>
> Regards
>
> Frank
>
> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in message
> news:fjp3ic$paq$2@build.eclipse.org...
>> Frank,
>>
>> Thank you for your insight. Your approach sounds interesting, but how are
>> you going to guard against incompatibilities of the AGR "core", as you
>> refer to it, with future versions of Eclipse?
>>
>> Kindest regards,
>> B.
>>
>> Barbara Rosi-Schwartz
>> Etish Limited [http://www.etish.org]
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> ^...^
>> / o,o \ The proud parents of Useme
>> |) ::: (| The Open Requirements Management Tool
>> ====w=w==== [https://useme.dev.java.net]
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>> Frank Froehlich wrote:
>>> Hi,
>>>
>>> hm, hard to say, I'm not already over that point. It is not a fully
>>> developed plan but currently I'm tending toward taking the AGR code, make
>>> it independent from the TPTP platform and consider it as a self written
>>> testing tool. Even if this would mean a not insignificant effort, it
>>> would open up chances and new vistas. I'm a little unsatisfied with some
>>> of the TPTP testing tool characteristics (the adoption of the UML2
>>> testing profile for example). Hence, I would adapt some things to my
>>> needs. For example the structure of a test suite is too simple in my
>>> opinion. I'm missing test scenarios (which can be nested) and the
>>> possibility for declaring precondition and cleanup steps which not
>>> necessarily are automated GUI actions. The AGR core, i.e. those parts of
>>> the software that perform the recording and drive the replay, is good and
>>> stable enough for using further on and worth to maintain.
>>>
>>> Right at the moment I simply do nothing. Because I'm already running a
>>> more or less heavily adapted private copy of AGR (which contains a number
>>> of improvements, enhancements and bug fixes), I feel fit enough to come
>>> over problems that arise sooner or later.
>>>
>>> Regards
>>>
>>> Frank
>>>
>>> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in
>>> message news:fjm1pc$5g4$1@build.eclipse.org...
>>>> Hello everybody.
>>>>
>>>> Following the effective demise of AGR as a tool for functional testing,
>>>> I am trying to come to grips with a possible alternative for our Eclipse
>>>> development effort.
>>>>
>>>> Having read the inspiring article by David Black,
>>>> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
>>>> I am exploring the possibility of moving away from the record/play back
>>>> paradigm and of using JUnit based tests for my functional testing. I
>>>> know that, in Eclipse, I have two options, namely the standard PDE JUnit
>>>> Plug-in tests and the TPTP JUnit Plug-in tests. However I am not really
>>>> familiar with either one and I find myself in the dark as to what
>>>> differences, pros and cons the two approaches have. If anybody has
>>>> reference material to point me to or any useful information, I would be
>>>> extremely grateful.
>>>>
>>>> TIA,
>>>> B.
>>>>
>>>> --
>>>> Barbara Rosi-Schwartz
>>>> Etish Limited [http://www.etish.org]
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> ^...^
>>>> / o,o \ The proud parents of Useme
>>>> |) ::: (| The Open Requirements Management Tool
>>>> ====w=w==== [https://useme.dev.java.net]
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
Re: Post AGR recommendations? [message #120639 is a reply to message #120626] Mon, 14 January 2008 11:24 Go to previous messageGo to next message
Paul Slauenwhite is currently offline Paul SlauenwhiteFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Jimmy, Frank, and Barbara,
Given your interest in continuing with the AGR, would either of you
three be interested in contributing to the TPTP project to keep this
component in production?

Paul
"Jimmy Jin" <jimmyjin.jxm@gmail.com> wrote in message
news:fmdfgo$k88$1@build.eclipse.org...
> Hi, Frank,
>
> We have the same idea as yours to split the AGR core (playback engine) out
> and create a standalone plug-in, so that we don't need to tight to TPTP,
> especially when playback. Currently, we already partially did that, except
> the dependency on the EMF model in TPTP and some other models used by AGR
> for TestSuite, etc. Here just share with you our way and maybe we can
> exchange ideas on this more. :-)
>
> 1. Create a new runner, so that the execution of testsuite can be
> triggered without using Agent Controller. Now we can select a testsuite
> file and run it in current Eclipse context successfully.
> 2. Removing all the recording GUI related classes. For some model classes
> in TPTP used by AGR, just copy certain TPTP plug-in jar file into the AGR
> plug-in and remove the external dependency. Since these are just models,
> they have much less external dependencies further.
> 3. For EMF model dependencies, we are thinking about storing the testsuite
> files as pure XML file, instead of EMF model file. Then the dependency can
> be removed.
>
> Regards,
> Jimmy Jin
>
> Frank Froehlich wrote:
>> Hi Barbara,
>>
>> the AGR core is pure SWT. The same level that David Black proposes to use
>> (good article btw, thanks). As long as the Eclipse GUI is SWT based the
>> code should work and should need just a small amount of maintenance
>> effort. Once you have a macro loaded (read from disk in whichever format)
>> you can easily feed at least the replay engine. Recording is a little bit
>> more difficult but manageable. The hard parts reside in different areas:
>> 1. The heavy dependency on the TPTP project framework (platform and
>> testing). 2. The close coupling with the UML2 testing profile 3. I
>> currently don't know how TPTPish the AutomationClientAdapter is and how
>> to emulate the start of an Eclipse instance with automated test
>> execution - some research task for me.
>>
>> Anyway, my vision is once having a Plug-in with minimum prereqs that
>> allows me to do the same things that AGR provides at the moment. Maybe
>> stripping down AGR could be a (the) key for performing automated GUI
>> tests on RCP applications too. It is a question of time (and knowledge, I
>> know) to cope with the task. At the moment I tend to tackle this task. I
>> just need some more days (or better: nights) to come to a decision.
>>
>> Regards
>>
>> Frank
>>
>> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in
>> message news:fjp3ic$paq$2@build.eclipse.org...
>>> Frank,
>>>
>>> Thank you for your insight. Your approach sounds interesting, but how
>>> are you going to guard against incompatibilities of the AGR "core", as
>>> you refer to it, with future versions of Eclipse?
>>>
>>> Kindest regards,
>>> B.
>>>
>>> Barbara Rosi-Schwartz
>>> Etish Limited [http://www.etish.org]
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> ^...^
>>> / o,o \ The proud parents of Useme
>>> |) ::: (| The Open Requirements Management Tool
>>> ====w=w==== [https://useme.dev.java.net]
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>> Frank Froehlich wrote:
>>>> Hi,
>>>>
>>>> hm, hard to say, I'm not already over that point. It is not a fully
>>>> developed plan but currently I'm tending toward taking the AGR code,
>>>> make it independent from the TPTP platform and consider it as a self
>>>> written testing tool. Even if this would mean a not insignificant
>>>> effort, it would open up chances and new vistas. I'm a little
>>>> unsatisfied with some of the TPTP testing tool characteristics (the
>>>> adoption of the UML2 testing profile for example). Hence, I would adapt
>>>> some things to my needs. For example the structure of a test suite is
>>>> too simple in my opinion. I'm missing test scenarios (which can be
>>>> nested) and the possibility for declaring precondition and cleanup
>>>> steps which not necessarily are automated GUI actions. The AGR core,
>>>> i.e. those parts of the software that perform the recording and drive
>>>> the replay, is good and stable enough for using further on and worth to
>>>> maintain.
>>>>
>>>> Right at the moment I simply do nothing. Because I'm already running a
>>>> more or less heavily adapted private copy of AGR (which contains a
>>>> number of improvements, enhancements and bug fixes), I feel fit enough
>>>> to come over problems that arise sooner or later.
>>>>
>>>> Regards
>>>>
>>>> Frank
>>>>
>>>> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in
>>>> message news:fjm1pc$5g4$1@build.eclipse.org...
>>>>> Hello everybody.
>>>>>
>>>>> Following the effective demise of AGR as a tool for functional
>>>>> testing, I am trying to come to grips with a possible alternative for
>>>>> our Eclipse development effort.
>>>>>
>>>>> Having read the inspiring article by David Black,
>>>>> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
>>>>> I am exploring the possibility of moving away from the record/play
>>>>> back paradigm and of using JUnit based tests for my functional
>>>>> testing. I know that, in Eclipse, I have two options, namely the
>>>>> standard PDE JUnit Plug-in tests and the TPTP JUnit Plug-in tests.
>>>>> However I am not really familiar with either one and I find myself in
>>>>> the dark as to what differences, pros and cons the two approaches
>>>>> have. If anybody has reference material to point me to or any useful
>>>>> information, I would be extremely grateful.
>>>>>
>>>>> TIA,
>>>>> B.
>>>>>
>>>>> --
>>>>> Barbara Rosi-Schwartz
>>>>> Etish Limited [http://www.etish.org]
>>>>>
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>
>>>>> ^...^
>>>>> / o,o \ The proud parents of Useme
>>>>> |) ::: (| The Open Requirements Management Tool
>>>>> ====w=w==== [https://useme.dev.java.net]
>>>>>
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
Re: Post AGR recommendations? [message #121043 is a reply to message #120639] Fri, 18 January 2008 23:01 Go to previous messageGo to next message
Jimmy Jin is currently offline Jimmy JinFriend
Messages: 32
Registered: July 2009
Member
Hi, Paul,

I think I will be willing to contribute some fixes, enhancements and
ideas for AGR, but so far I don't know how to do that and how much
effort I may need to do that. I need some guidance in these areas.

Feel free to give me email.

Regards,
Jimmy Jin


Paul Slauenwhite wrote:
> Hi Jimmy, Frank, and Barbara,
> Given your interest in continuing with the AGR, would either of you
> three be interested in contributing to the TPTP project to keep this
> component in production?
>
> Paul
> "Jimmy Jin" <jimmyjin.jxm@gmail.com> wrote in message
> news:fmdfgo$k88$1@build.eclipse.org...
>> Hi, Frank,
>>
>> We have the same idea as yours to split the AGR core (playback engine) out
>> and create a standalone plug-in, so that we don't need to tight to TPTP,
>> especially when playback. Currently, we already partially did that, except
>> the dependency on the EMF model in TPTP and some other models used by AGR
>> for TestSuite, etc. Here just share with you our way and maybe we can
>> exchange ideas on this more. :-)
>>
>> 1. Create a new runner, so that the execution of testsuite can be
>> triggered without using Agent Controller. Now we can select a testsuite
>> file and run it in current Eclipse context successfully.
>> 2. Removing all the recording GUI related classes. For some model classes
>> in TPTP used by AGR, just copy certain TPTP plug-in jar file into the AGR
>> plug-in and remove the external dependency. Since these are just models,
>> they have much less external dependencies further.
>> 3. For EMF model dependencies, we are thinking about storing the testsuite
>> files as pure XML file, instead of EMF model file. Then the dependency can
>> be removed.
>>
>> Regards,
>> Jimmy Jin
>>
>> Frank Froehlich wrote:
>>> Hi Barbara,
>>>
>>> the AGR core is pure SWT. The same level that David Black proposes to use
>>> (good article btw, thanks). As long as the Eclipse GUI is SWT based the
>>> code should work and should need just a small amount of maintenance
>>> effort. Once you have a macro loaded (read from disk in whichever format)
>>> you can easily feed at least the replay engine. Recording is a little bit
>>> more difficult but manageable. The hard parts reside in different areas:
>>> 1. The heavy dependency on the TPTP project framework (platform and
>>> testing). 2. The close coupling with the UML2 testing profile 3. I
>>> currently don't know how TPTPish the AutomationClientAdapter is and how
>>> to emulate the start of an Eclipse instance with automated test
>>> execution - some research task for me.
>>>
>>> Anyway, my vision is once having a Plug-in with minimum prereqs that
>>> allows me to do the same things that AGR provides at the moment. Maybe
>>> stripping down AGR could be a (the) key for performing automated GUI
>>> tests on RCP applications too. It is a question of time (and knowledge, I
>>> know) to cope with the task. At the moment I tend to tackle this task. I
>>> just need some more days (or better: nights) to come to a decision.
>>>
>>> Regards
>>>
>>> Frank
>>>
>>> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in
>>> message news:fjp3ic$paq$2@build.eclipse.org...
>>>> Frank,
>>>>
>>>> Thank you for your insight. Your approach sounds interesting, but how
>>>> are you going to guard against incompatibilities of the AGR "core", as
>>>> you refer to it, with future versions of Eclipse?
>>>>
>>>> Kindest regards,
>>>> B.
>>>>
>>>> Barbara Rosi-Schwartz
>>>> Etish Limited [http://www.etish.org]
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> ^...^
>>>> / o,o \ The proud parents of Useme
>>>> |) ::: (| The Open Requirements Management Tool
>>>> ====w=w==== [https://useme.dev.java.net]
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>>
>>>> Frank Froehlich wrote:
>>>>> Hi,
>>>>>
>>>>> hm, hard to say, I'm not already over that point. It is not a fully
>>>>> developed plan but currently I'm tending toward taking the AGR code,
>>>>> make it independent from the TPTP platform and consider it as a self
>>>>> written testing tool. Even if this would mean a not insignificant
>>>>> effort, it would open up chances and new vistas. I'm a little
>>>>> unsatisfied with some of the TPTP testing tool characteristics (the
>>>>> adoption of the UML2 testing profile for example). Hence, I would adapt
>>>>> some things to my needs. For example the structure of a test suite is
>>>>> too simple in my opinion. I'm missing test scenarios (which can be
>>>>> nested) and the possibility for declaring precondition and cleanup
>>>>> steps which not necessarily are automated GUI actions. The AGR core,
>>>>> i.e. those parts of the software that perform the recording and drive
>>>>> the replay, is good and stable enough for using further on and worth to
>>>>> maintain.
>>>>>
>>>>> Right at the moment I simply do nothing. Because I'm already running a
>>>>> more or less heavily adapted private copy of AGR (which contains a
>>>>> number of improvements, enhancements and bug fixes), I feel fit enough
>>>>> to come over problems that arise sooner or later.
>>>>>
>>>>> Regards
>>>>>
>>>>> Frank
>>>>>
>>>>> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in
>>>>> message news:fjm1pc$5g4$1@build.eclipse.org...
>>>>>> Hello everybody.
>>>>>>
>>>>>> Following the effective demise of AGR as a tool for functional
>>>>>> testing, I am trying to come to grips with a possible alternative for
>>>>>> our Eclipse development effort.
>>>>>>
>>>>>> Having read the inspiring article by David Black,
>>>>>> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
>>>>>> I am exploring the possibility of moving away from the record/play
>>>>>> back paradigm and of using JUnit based tests for my functional
>>>>>> testing. I know that, in Eclipse, I have two options, namely the
>>>>>> standard PDE JUnit Plug-in tests and the TPTP JUnit Plug-in tests.
>>>>>> However I am not really familiar with either one and I find myself in
>>>>>> the dark as to what differences, pros and cons the two approaches
>>>>>> have. If anybody has reference material to point me to or any useful
>>>>>> information, I would be extremely grateful.
>>>>>>
>>>>>> TIA,
>>>>>> B.
>>>>>>
>>>>>> --
>>>>>> Barbara Rosi-Schwartz
>>>>>> Etish Limited [http://www.etish.org]
>>>>>>
>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>
>>>>>> ^...^
>>>>>> / o,o \ The proud parents of Useme
>>>>>> |) ::: (| The Open Requirements Management Tool
>>>>>> ====w=w==== [https://useme.dev.java.net]
>>>>>>
>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
Re: Post AGR recommendations? [message #121133 is a reply to message #121043] Mon, 21 January 2008 11:24 Go to previous message
Paul Slauenwhite is currently offline Paul SlauenwhiteFriend
Messages: 975
Registered: July 2009
Senior Member
Hi Jimmy,
The best way is to attach patches and automated test cases to Bugziila,
making sure you following the Eclipse Legal Process
(http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf). Once a patch
and test cases are contributed by you (and your company, if applicable) for
EPL and they have been reviewed by the lead committer for the component, we
can integrate the fix.

Paul
"Jimmy Jin" <jimmyjin.jxm@gmail.com> wrote in message
news:fmrb49$ir2$1@build.eclipse.org...
> Hi, Paul,
>
> I think I will be willing to contribute some fixes, enhancements and ideas
> for AGR, but so far I don't know how to do that and how much effort I may
> need to do that. I need some guidance in these areas.
>
> Feel free to give me email.
>
> Regards,
> Jimmy Jin
>
>
> Paul Slauenwhite wrote:
>> Hi Jimmy, Frank, and Barbara,
>> Given your interest in continuing with the AGR, would either of you
>> three be interested in contributing to the TPTP project to keep this
>> component in production?
>>
>> Paul
>> "Jimmy Jin" <jimmyjin.jxm@gmail.com> wrote in message
>> news:fmdfgo$k88$1@build.eclipse.org...
>>> Hi, Frank,
>>>
>>> We have the same idea as yours to split the AGR core (playback engine)
>>> out and create a standalone plug-in, so that we don't need to tight to
>>> TPTP, especially when playback. Currently, we already partially did
>>> that, except the dependency on the EMF model in TPTP and some other
>>> models used by AGR for TestSuite, etc. Here just share with you our way
>>> and maybe we can exchange ideas on this more. :-)
>>>
>>> 1. Create a new runner, so that the execution of testsuite can be
>>> triggered without using Agent Controller. Now we can select a testsuite
>>> file and run it in current Eclipse context successfully.
>>> 2. Removing all the recording GUI related classes. For some model
>>> classes in TPTP used by AGR, just copy certain TPTP plug-in jar file
>>> into the AGR plug-in and remove the external dependency. Since these are
>>> just models, they have much less external dependencies further.
>>> 3. For EMF model dependencies, we are thinking about storing the
>>> testsuite files as pure XML file, instead of EMF model file. Then the
>>> dependency can be removed.
>>>
>>> Regards,
>>> Jimmy Jin
>>>
>>> Frank Froehlich wrote:
>>>> Hi Barbara,
>>>>
>>>> the AGR core is pure SWT. The same level that David Black proposes to
>>>> use (good article btw, thanks). As long as the Eclipse GUI is SWT based
>>>> the code should work and should need just a small amount of maintenance
>>>> effort. Once you have a macro loaded (read from disk in whichever
>>>> format) you can easily feed at least the replay engine. Recording is a
>>>> little bit more difficult but manageable. The hard parts reside in
>>>> different areas: 1. The heavy dependency on the TPTP project framework
>>>> (platform and testing). 2. The close coupling with the UML2 testing
>>>> profile 3. I currently don't know how TPTPish the
>>>> AutomationClientAdapter is and how to emulate the start of an Eclipse
>>>> instance with automated test execution - some research task for me.
>>>>
>>>> Anyway, my vision is once having a Plug-in with minimum prereqs that
>>>> allows me to do the same things that AGR provides at the moment. Maybe
>>>> stripping down AGR could be a (the) key for performing automated GUI
>>>> tests on RCP applications too. It is a question of time (and knowledge,
>>>> I know) to cope with the task. At the moment I tend to tackle this
>>>> task. I just need some more days (or better: nights) to come to a
>>>> decision.
>>>>
>>>> Regards
>>>>
>>>> Frank
>>>>
>>>> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in
>>>> message news:fjp3ic$paq$2@build.eclipse.org...
>>>>> Frank,
>>>>>
>>>>> Thank you for your insight. Your approach sounds interesting, but how
>>>>> are you going to guard against incompatibilities of the AGR "core", as
>>>>> you refer to it, with future versions of Eclipse?
>>>>>
>>>>> Kindest regards,
>>>>> B.
>>>>>
>>>>> Barbara Rosi-Schwartz
>>>>> Etish Limited [http://www.etish.org]
>>>>>
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>
>>>>> ^...^
>>>>> / o,o \ The proud parents of Useme
>>>>> |) ::: (| The Open Requirements Management Tool
>>>>> ====w=w==== [https://useme.dev.java.net]
>>>>>
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>
>>>>>
>>>>> Frank Froehlich wrote:
>>>>>> Hi,
>>>>>>
>>>>>> hm, hard to say, I'm not already over that point. It is not a fully
>>>>>> developed plan but currently I'm tending toward taking the AGR code,
>>>>>> make it independent from the TPTP platform and consider it as a self
>>>>>> written testing tool. Even if this would mean a not insignificant
>>>>>> effort, it would open up chances and new vistas. I'm a little
>>>>>> unsatisfied with some of the TPTP testing tool characteristics (the
>>>>>> adoption of the UML2 testing profile for example). Hence, I would
>>>>>> adapt some things to my needs. For example the structure of a test
>>>>>> suite is too simple in my opinion. I'm missing test scenarios (which
>>>>>> can be nested) and the possibility for declaring precondition and
>>>>>> cleanup steps which not necessarily are automated GUI actions. The
>>>>>> AGR core, i.e. those parts of the software that perform the recording
>>>>>> and drive the replay, is good and stable enough for using further on
>>>>>> and worth to maintain.
>>>>>>
>>>>>> Right at the moment I simply do nothing. Because I'm already running
>>>>>> a more or less heavily adapted private copy of AGR (which contains a
>>>>>> number of improvements, enhancements and bug fixes), I feel fit
>>>>>> enough to come over problems that arise sooner or later.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Frank
>>>>>>
>>>>>> "Barbara Rosi-Schwartz" <Barbara.Rosi-Schwartz@Etish.org> wrote in
>>>>>> message news:fjm1pc$5g4$1@build.eclipse.org...
>>>>>>> Hello everybody.
>>>>>>>
>>>>>>> Following the effective demise of AGR as a tool for functional
>>>>>>> testing, I am trying to come to grips with a possible alternative
>>>>>>> for our Eclipse development effort.
>>>>>>>
>>>>>>> Having read the inspiring article by David Black,
>>>>>>> http://codecurl.wordpress.com/2007/11/03/automated-eclipse-g ui-testing-the-quick-and-simple-way/,
>>>>>>> I am exploring the possibility of moving away from the record/play
>>>>>>> back paradigm and of using JUnit based tests for my functional
>>>>>>> testing. I know that, in Eclipse, I have two options, namely the
>>>>>>> standard PDE JUnit Plug-in tests and the TPTP JUnit Plug-in tests.
>>>>>>> However I am not really familiar with either one and I find myself
>>>>>>> in the dark as to what differences, pros and cons the two approaches
>>>>>>> have. If anybody has reference material to point me to or any useful
>>>>>>> information, I would be extremely grateful.
>>>>>>>
>>>>>>> TIA,
>>>>>>> B.
>>>>>>>
>>>>>>> --
>>>>>>> Barbara Rosi-Schwartz
>>>>>>> Etish Limited [http://www.etish.org]
>>>>>>>
>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>
>>>>>>> ^...^
>>>>>>> / o,o \ The proud parents of Useme
>>>>>>> |) ::: (| The Open Requirements Management Tool
>>>>>>> ====w=w==== [https://useme.dev.java.net]
>>>>>>>
>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
Previous Topic:How to know full list of TPTP Profiler features.
Next Topic:Restrictions of AGR for GEF
Goto Forum:
  


Current Time: Tue Mar 19 04:12:25 GMT 2024

Powered by FUDForum. Page generated in 0.26356 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top