| Automated GUI Recorder capabilities [message #51067] |
Fri, 20 January 2006 10:14  |
 Shlomy Reinstein
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
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 20:42  |
No real name
Messages: 404
Registered: July 2009 |
Senior Member |
|
|
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
>
>
>
>
>
>
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04176 seconds
] 
Search
Help
Register
Login
Home
