Testing Design: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
No edit summary
No edit summary
 
(14 intermediate revisions by one other user not shown)
Line 1: Line 1:
==Requirements==
This page moved [http://www.paraview.org/Wiki/Testing_design here]
 
* Support easy testcase creation for user contributed tests.
* Support playback and recording of testcases.
* Support hand editing of testcases.
* Test cases can be scripts (but we support a trivial "metafile" format, so we aren't dependent on any given script engine for testing).
* Test commands are stored with a high level of abstraction instead of low-level events, to reduce test-case breakage (e.g. "button push" instead of "mouse down at x,y location").
* Test commands still work if widget moves to new location in object tree (docking window can be top level or child), to reduce test-case breakage - implies a flat naming scheme for UI components.
* Test commands not completely tied to type of object (spin box & slider bar represent the same thing & swapping them should make test work still).
* Support verification - check that a line edit has the right text at a certain point in the test, or (more complex) retrieve data from VTK objects.
* Support an inspector to navigate the object tree as an aid for hand-editing.
 
==Design==
 
The testing framework is centered around "recording" and "playback" of user interaction.
 
For recording, an instance of pqEventTranslator is created, which intercepts Qt events for the entire application.  pqEventTranslator manages a collection of pqWidgetEventTranslator objects, which are specialized for specific Qt widget types.  The translators convert low-level Qt events ("mouse move", "button down", "button up") into higher-level ParaQ events that can be usefully serialized and played back ("button activated").  Each high-level event is encapsulated in three strings: the name of the widget, the name of the event, and optional arguments to the event.  Multiple recording "back ends" can be attached to pqEventTranslator, to serialize events - pqEventObserverStdout and pqEventObserverXML are existing examples, presumably a pqEventObserverPython object could "store" events in Python code.  pqWidgetEventTranslator-derivatives will be provided for all "native" Qt widgets, so recording will "just work" for any UI created with stock Qt components.  For non-standard widgets, developers may create their own pqWidgetEventTranslator implementations and add them to pqEventTranslator at runtime.
 
For playback, an instance of pqEventPlayer is created.  pqEventPlayer manages a collection of pqWidgetEventPlayer objects, which are responsible for converting high-level ParaQ events into interaction with the UI.  Note that there is not necessarily a one-to-one correspondence between pwWidgetEventTranslastor and pqWidgetEventPlayer objects - a single pqAbstractIntEventPlayer object is capable of handling events generated by both pqSpinBoxEventTranslator and pqAbstractSliderEventTranslator.  The latter two objects are separate due to dissimilar behavior between Qt objects, while pqAbstractIntEventPlayer can handle playback for both because they both "map" events to a common, abstract concept.  This makes it possible for a test case to continue working when the UI changes from one compatible widget (e.g. SpinBox) to another (Dial or Slider).

Latest revision as of 12:01, 23 August 2006

This page moved here