Difference between revisions of "Talk:GUI Testing"
m |
|||
| Line 29: | Line 29: | ||
If possible create framework in which strategy can easily be changed if later we see that one or the other would have been better. | If possible create framework in which strategy can easily be changed if later we see that one or the other would have been better. | ||
| + | |||
| + | |||
| + | ===TODO=== | ||
| + | |||
| + | Have a look at FIT: http://fit.c2.com/ | ||
Latest revision as of 10:48, 3 November 2006
Proposal for next steps
Framework
Create framework for GUI testing done through programming. This is needed to create test cases by hand and to insert assertions into automatically created test cases.
- Find widgets according to name or other properties
- Used to read widget data and assert test conditions
- Issue events on the GUI
- Keyboard
- Mouse movement
- Mouse clicks
- Mouse dragging
Capturing
To automatically create test cases a capturing tool could be created. The tool could export Eiffel classes (as executable test cases) which can be improved and maintained by hand.
- Wait for Andreas Leitner's input on capturing (Mid-November)
Replay
To execute the test cases we have to decide on a strategy how the test case can interact with the application.
- My favorite strategy
- Use Debugger (only for non-finalzed applications, but the most interesting solution)
- Most realistic strategy
- Compile test into application (easiest communication between test and application)
If possible create framework in which strategy can easily be changed if later we see that one or the other would have been better.
TODO
Have a look at FIT: http://fit.c2.com/
