| Automated GUI Recorder capabilities [message #51067] |
Fri, 20 January 2006 05:14  |
Eclipse User |
|
|
|
Hi,
I wish to test my Eclipse UI plugin using the AGR. To be able to do that, I
need the AGR to have the capabilities below. Can you tell me if there are
plans to add these capabilities to the AGR, and if so, what is the schedule?
Also, if there are already guidelines/ideas how to add these capabilities,
I'd be very happy to learn them.
- Support for native (Windows) widgets.
- Basic control commands, such as loops and conditionals, where some of the
parameters (number of iterations / conditions) are known at the beginning of
the test, but some are only known during the execution of the test. For
example, I record a sequence of actions inside an editor, and then (during
playback) I want these actions to be played in a loop, where the number of
iterations in the loop is written in the first line of that file (and the
file can change between invocations of the test).
One final question: The AGR is currently published as a "technology
preview". Does this mean that the internal design of the AGR or the format
of the generated XML can change dramatically when the AGR is released?
Thanks,
Shlomy
|
|
|
| Re: Automated GUI Recorder capabilities [message #51179 is a reply to message #51067] |
Fri, 20 January 2006 15:42  |
| Eclipse User |
|
|
|
Hi Shlomy,
> - Support for native (Windows) widgets.
The recorder is only dependent on what events are reported by SWT. Anything
that is not reported will not get recorded. I have opened feature:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=124717 to follow this up with
the SWT folks and see if they can introduce an extra layer or a wrapper for
such dialogs.
AGR will not likely support any OS-dependent mechanism for being able to
record user interactions with native windows. The only native dialog that
is commonly used in Eclipse applications is the Browse window. Applications
usually provide a text box for being able to enter the path as opposed to
using the browse button.
It will help if you can describe to me your specific need for this feature.
I'm interested to know if there is any work around.
> - Basic control commands, such as loops and conditionals, where some of
the
> parameters (number of iterations / conditions) are known at the beginning
of
> the test, but some are only known during the execution of the test. For
> example, I record a sequence of actions inside an editor, and then (during
> playback) I want these actions to be played in a loop, where the number of
> iterations in the loop is written in the first line of that file (and the
> file can change between invocations of the test).
There is currently a mechanism in place for adding loops to the execution
behavior of test suites, but the iteration number can't be parameterized.
The execution behavior also does not include any mechanism for adding
conditional statements. Users won't probably be able to specify an argument
that they store in an arbitrary editor but it does make sense to have
iteration numbers parameterized based on datapool entries (which can be
programmatically modified in the middle of your test execution using a
verification hook).
I have opened feature https://bugs.eclipse.org/bugs/show_bug.cgi?id=124720
to try and address this need. Neither one of the features opened will be
considered for 4.2. They may get accepted in 4.3+.
> One final question: The AGR is currently published as a "technology
> preview". Does this mean that the internal design of the AGR or the format
> of the generated XML can change dramatically when the AGR is released?
No. The format of the macro will not change drastically to cause any
breakage.
Thank you for your interest.
"Shlomy Reinstein" <sreinstein@e-sim.co.il> wrote in message
news:dqqd5q$vjo$1@utils.eclipse.org...
> Hi,
>
> I wish to test my Eclipse UI plugin using the AGR. To be able to do that,
I
> need the AGR to have the capabilities below. Can you tell me if there are
> plans to add these capabilities to the AGR, and if so, what is the
schedule?
> Also, if there are already guidelines/ideas how to add these capabilities,
> I'd be very happy to learn them.
>
> - Support for native (Windows) widgets.
> - Basic control commands, such as loops and conditionals, where some of
the
> parameters (number of iterations / conditions) are known at the beginning
of
> the test, but some are only known during the execution of the test. For
> example, I record a sequence of actions inside an editor, and then (during
> playback) I want these actions to be played in a loop, where the number of
> iterations in the loop is written in the first line of that file (and the
> file can change between invocations of the test).
>
> One final question: The AGR is currently published as a "technology
> preview". Does this mean that the internal design of the AGR or the format
> of the generated XML can change dramatically when the AGR is released?
>
> Thanks,
> Shlomy
>
>
>
>
>
>
|
|
|
|
| Re: Automated GUI Recorder capabilities [message #51315 is a reply to message #51207] |
Mon, 23 January 2006 15:04 |
| Eclipse User |
|
|
|
It seems like what you're looking for is a single solution for being able to
test an application with Smalltalk GUI and SWT objects.
If your Smalltalk GUI objects are contained by an SWT container, then you
can resort to position-based recording to create your test cases. As you
move your application to Eclipse and start using SWT object in place of
Smalltalk GUI objects, you can replace the position-based parts of your test
case with object-based recordings.
"Shlomy Reinstein" <sreinstein@e-sim.co.il> wrote in message
news:dqshmd$qg5$1@utils.eclipse.org...
> Thanks for the quick reply.
> The plugin I wish to test with the AGR is actually based on a Smalltalk
> application (with a Smalltalk GUI toolkit) which is gradually being
migrated
> to Eclipse. It will take some time to migrate the entire application GUI
to
> Eclipse, and until it fully migrated I need a way to test the Smalltalk
GUI
> as well as the Eclipse UI plugin. The Smalltalk GUI toolkit is
heavy-weight,
> like SWT. The editors and some of the views of the application files are
> actually Smalltalk GUI panes that are made children of the appropriate SWT
> Composite widgets.
>
> Shlomy
>
> "Ali Mehregani" <amehrega@ca.ibm.com> wrote in message
> news:dqri0t$jed$1@utils.eclipse.org...
> > Hi Shlomy,
> >
> >> - Support for native (Windows) widgets.
> > The recorder is only dependent on what events are reported by SWT.
> > Anything
> > that is not reported will not get recorded. I have opened feature:
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=124717 to follow this up
> > with
> > the SWT folks and see if they can introduce an extra layer or a wrapper
> > for
> > such dialogs.
> > AGR will not likely support any OS-dependent mechanism for being able to
> > record user interactions with native windows. The only native dialog
that
> > is commonly used in Eclipse applications is the Browse window.
> > Applications
> > usually provide a text box for being able to enter the path as opposed
to
> > using the browse button.
> > It will help if you can describe to me your specific need for this
> > feature.
> > I'm interested to know if there is any work around.
> >
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.04900 seconds
Home