Qt Autotest Environment: Difference between revisions
(Add link to "Common problems" section in "Writing Unit Tests".) |
(gitorious is no more) |
||
Line 1: | Line 1: | ||
[[Category:Developing_Qt::Guidelines]] | [[Category:Developing_Qt::Guidelines]] | ||
Line 59: | Line 58: | ||
'''qt-test-server.troll.no''' - [http://code.qt.io/cgit/qt/qt.git/tree/tests/auto/q3socket/tst_qsocket.cpp q3socket] | '''qt-test-server.troll.no''' - [http://code.qt.io/cgit/qt/qt.git/tree/tests/auto/q3socket/tst_qsocket.cpp q3socket] | ||
The network test server can be set up by following the '''qtqa/sysadmin.git''' repository | The network test server can be set up by following the '''qtqa/sysadmin.git''' repository; see [http://code.qt.io/cgit/qtqa/sysadmin.git/tree/README.network_test_server.txt instructions here] | ||
=== DBus tests === | === DBus tests === |
Revision as of 07:36, 14 April 2020
Introduction
Many Qt autotests require some environment setup to work correctly. This page is an attempt to document precisely what this environment is.
Note that this is "best-effort" documentation. It should not be interpreted as coding standards for autotests, in fact quite the opposite - many of the requirements here are due to a lack of coding standards. Some of these environmental requirements can be considered problems with the autotests which should be fixed.
The information may become outdated as autotests change. The current version of this page was written for Qt 4.5 and 4.6.
Qt build
Qt autotests require that Qt be built for testing itself. This will make some additional symbols be exported and some additional code be built to support it. To enable such a build, when you configure Qt, remember to pass the option -developer-build:
./configure -developer-build -prefix $PWD
The main changes to the Qt build are:
- QT_INTERNAL_BUILD is set, so code can #ifdef to determine whether to enable the additional code
- Q_AUTOTEST_EXPORT is defined to exporting the symbols
Note also that Qt tests have only been tested with a non-installing Qt (the -prefix $PWD option above). The test project files override the make install target, so they are not installable. And Qt doesn't work at all if it's not at its installation path.
Shadow builds
Don't use shadow builds.
Some tests assume that their source and build directory are the same directory in order to find testdata.
Working directory
When the test is invoked, the working directory must be the directory containing the test's source (and binary, due to "no shadow builds" rule).
For tests with multiple subdirectories, use the top level directory for that test (e.g. for the qprocess test, run from tests/auto/qprocess, even though the .pro file for the test is at tests/auto/qprocess/test).
Some tests read testdata from files found relative to the current working directory.
Reference: qscriptv8testsuite finds testdata relative to QDir
Environment variables
QTDIR: path to Qt build directory. bic reads headers from $QTDIR/include
QTSRCDIR: path to Qt source directory (same as QTDIR due to no shadow builds rule). Strictly speaking, does not seem required, as all tests which use this fall back on QTDIR, which is correct anyway due to "no shadow builds" rule. xmlpatternsxqts adds $QTSRCDIR/include to INCLUDEPATH
PATH: must include bin directory for the tested Qt, in front of any bin directory from other Qt versions. rcc assumes <code> rcc' is in PATH
Network tests
In /etc/hosts (Unix) or windir32\drivers\etc\hosts (Windows), set up some hostnames to point to a server running particular test services.
The hostnames to be set up are:
qt-test-server and qt-test-server.qt-test-net- network-settings.h
qt-test-server.troll.no - q3socket
The network test server can be set up by following the qtqa/sysadmin.git repository; see instructions here
DBus tests
The DBus tests require a dbus session bus to be running.
Common problems with test machine setup
Please see here for problems that can appear when running the auto tests.