Difference between revisions of "GUI Capture"
| Line 3: | Line 3: | ||
==Overview== | ==Overview== | ||
| − | + | During the recording of a test case, all events of the AUT are recorded for later replay. | |
==Approaches== | ==Approaches== | ||
| Line 28: | Line 28: | ||
* Additional information is available (e.g. widget name) | * Additional information is available (e.g. widget name) | ||
;Contra | ;Contra | ||
| − | * | + | * Event recording and its activation is part of the AUT |
* Only Vision2 can be captured | * Only Vision2 can be captured | ||
Revision as of 14:30, 1 November 2006
Overview
During the recording of a test case, all events of the AUT are recorded for later replay.
Approaches
There are different approaches for capturing GUI events:
Low Level Hooks
On Windwos it is possible to capture low level window events. Through these it is possible for a capturing tool to launch the AUT and then install a hook to receive all input events. This should also be the case for Unix although it is not checked yet.
- Pro
- Capturing tool and AUT are separate
- Can capture events from any application
- Contra
- Only receive low level events. No information about focus-changing for example.
- Unclear how to receive additional information about AUT like current active widget or widget name of clicked widgets
Eiffel Level Hooks
For Vision2 we could implement a capturing mode. When this mode is activated, all events - including focus-chaning events or other higher level events - could be exported to a file. The implementation would mainly be done in the underlying toolkit (WEL and GTK implementation).
- Pro
- Capturing of all events
- Additional information is available (e.g. widget name)
- Contra
- Event recording and its activation is part of the AUT
- Only Vision2 can be captured
