Question: The AUT has been ported from Qt 3 to Qt 4; how do I port the Squish Tests?
Answer:
In theory, the tests should continue to work since Squish works with both Qt 3 and Qt 4, although in practice things aren't necessarily so simple.
To help with this issue Squish has functions that automatically map accesses to old class names (e.g., those that have been renamed to start with Q3 instead of Q) wherever possible.
However, what usually happens is that when the AUT is ported a significant amount of the code gets rewritten and in many cases the developers use Qt 4-specific classes that have no (or no similar) equivalent in Qt 3. If this happens, then clearly the existing Squish tests will fail because they will be attempting to interact with objects that simply don't exist in the new AUT.
There are two approaches that can be taken in such cases: the tests can be recreated (e.g., rerecorded or rewritten), or they can be ported (i.e., edited to match the new AUT). Of those customers who have faced this problem, about half took one approach and half the other.
Which is the best approach probably depends on two key factors:
How much has the AUT changed as a result of the port? Some organizations try to keep the changes to the absolute minimum, just to accommodate the change in toolkit (perhaps using the Qt3Support module), while others take the opportunity to do a complete redesign and write lots of new code.
The degree of test script refactoring. If all scripts are plain recordings then they'll be more sensitive to changes in the GUI. Some test teams have refactored recorded tests or have written tests from scratch to produce scripts that have fewer accesses to AUT objects than recorded scripts use. As a result the main scripts are simpler and less dependent on the GUI. In such cases there is often less work to do when porting.
Our recommendation is not to try to use recorded scripts as is. Instead, we recommend refactoring the tests to create custom parameterized functions that will both make the scripts more readable and also more adaptable to AUT changes. Of course, it may be too late to do this if you are on the verge of switching from a Qt 3-based AUT to a Qt 4-based one.
In porting from Qt 4 to Qt 5, there should not be large breaks in Qt compatibility. To help our customers maintain their tests we are increasingly starting to abstract widgets from their concrete implementations. For example, we will provide APIs to verify the contents of a table without having to directly access the underlying Qt API — thus making scripts more robust in the face of toolkit changes. (Of course, we will still continue to provide full access to toolkit APIs.)