In general, it is necessary to perform testing of each application against all known layout Device Profiles, including those corresponding to devices that are available in the market.
However, it's also highly recommended that you perform complete scalability testing, even if this means that you will be testing Device Profiles that are not available in practice. By testing that your application is scalable in principle, it is more likely that your application will function in a reasonable way on unknown future devices, that may be released after your application is published. However, it also means that your layouts have been designed in a way that is easier to maintain.
Don't forget to test:
One approach to layout testing is to create a cut-down version of your application, which only includes the user interface, and any test code needed to exercise all of the application layouts, even without data sources such as web services. This makes it faster and easier to test the visual appearance, and can simplify dependencies on other components or external data sources.
For example, if there are elements in your interface that can only be accessed by making a phone call, you could consider turning this into a separate component that can be tested from within a test harness application.
It can be convenient and practical to use the different SDK environments to perform different kinds of testing:
Target testing also ensures that any dynamic timing behaviour of state changes, signal execution order etc, are correct, and all of these things can affect the final layout.
The best approach to testing complete scalabillty is using Qt in the desktop environment. The Qt application is contained within a window on the desktop, which means that you can resize the parent window using the mouse. This means that you can dynamically resize the "window" (in the desktop sense of the word), which gives a better visual impression of the relationships between the components.
It's important to know the extreme limits of your user interface design, and test that it looks good as you approach those limits. Here are some testing tips:
In order to test the DPI, see the ScaleFM example application. For example you could create a popup window for testing purposes that has buttons to change the DPI, without making any changes to your application layout. Alternatively, you could use the Setting Window as described below.
Note: As soon as you resize the desktop window, your screen size will no longer match one of the official Device Profiles. Therefore, if you have defined any Device Profile specific layout definition files, they will be invalid, and therefore the Category or generic layout defintions will be used. So, it's important to resize the window, change the DPI, and also test the specific Device Profiles. Only by completing all these tasks can you paint a complete picture of your application's layout behavior.
In order to more effectively test the supported Device Profiles in the desktop environment, consider including the settings window feature in your application. This allows you to select a specifc Device Profile for any application, and also to edit the DPI value.
To instantiate the settings window, add this code to your main() function:
SettingsWindow settingsWindow(view);
You must remember to test the scalability for each separate Page or view within your application, including when using popup windows.
The Qt Quick Components all provide excellent scalability, but you still need to ensure that they are interacting with your application layouts correctly.
Finally, always re-test every device profile after upgrading the import version of the Qt-components library, the import version of Qt Quick, the Qt Release used, or your application's layout definitions.