Early Testing Prototype

Early versions of the ParaQ client provided some bare-minimum prototyping of QtTestlib integration:

• See pqTestCases.h / pqTestCases.cxx for multiple test cases that are linked into the ParaQ client and can be run on-demand. These files can be conditionally compiled/linked to provided binaries with-or-without built-in testing.

• Although QtTestlib is geared towards unit-testing, it is possible to test the application (and the UI) as-a-whole. pqTestFileMenu::testFileOpen() opens the file browser dialog, tests to see that the dialog exists, then closes it.

• To perform UI testing, it is trivial to synthesize user input using QtTestLib, and/or emit signals. The fundamental problem is one of identity: how to you gain a reference to the correct Qt widget so your test case can send events to it / emit its signals? The approach taken in the client was to name all widgets, and use the appropriate QObject methods to look them up using a filesystem-like "path". This is a natural fit for the widget hierarchy used by Qt, but it suffers from the usual problems of changes in UI layout causing test cases to break, because the "path" to a given widget has changed. An alternative mechanism would be to "flatten" the hierarchy by assigning globally-unique names to every widget based on their function. Test code would still walk the Qt hierarchy to locate widgets, but would be more robust in the face of rearranged UI layout. In both cases, there is (necessarily) a strong coupling between test-case and naming convention.

• Regardless of naming convention, test-case-writers will likely need some type of "inspection" user interface to enable test authoring.

See Testing Design for more up-to-date information on the testing framework.