GUI Replay
Overview
In the replay phase a recorded sequence of events is replayed and the assertions are checked. The desired behaviour is as follows:
- The test cases can be compiled separate from the AUT.
- The AUT can be in finalized mode.
- Changes to the layout in the AUT don't have an impact on many tests, or at least is adapted easily or automatic.
Problems
Checking assertions
To check assertions the test has to access the current state of the AUT. In Eiffel this is a problem since no mechanism for this exist.
The closest you get is the debugger which can access non-finalized applications and read the current state as well as execute expressions.
| Method | Pro | Contra |
|---|---|---|
| Use debugger which can access non-finalized applications | Testprogram and AUT are completly separate | Can only debug non-finalized applications |
| Compile test into AUT | Easy to access state of AUT | Each test (or a group of tests) has to be compiled together with AUT |
| Provide interprocess communication | Testprogram and AUT are completly separate | Unclear how to provide interprocess communication in Eiffel |
| Screenshot comparison | Testprogram and AUT are completly separate | Very vulnerable to layout changes |
Layout changes
To be able to react on layout changes in the AUT, a test case should not consist of a series of events on certain positions, but rather as a series of events on certain widgets. If a widget can be identified by its name (or underlying command) the change of position would not affect a test case. For that to work, all widgets or commands should have a name (which does not necessarily has to be unique).
