2015-04-27 08:35:04 +02:00
|
|
|
QGIS unit tests
|
|
|
|
===============
|
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
# Building tests
|
2015-04-27 08:35:04 +02:00
|
|
|
|
|
|
|
Make sure that you have enabled building of tests in CMake.
|
2023-06-19 21:00:19 -04:00
|
|
|
`cmake -D ENABLE_TESTS=ON ..`
|
2015-04-27 08:35:04 +02:00
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
# Setting up the test environment
|
2015-04-27 08:35:04 +02:00
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
Some tests require setting up a test environment.
|
|
|
|
Below some information about how to set such environment up.
|
2015-04-27 08:35:04 +02:00
|
|
|
|
2022-06-08 17:33:59 +02:00
|
|
|
## Docker based environment
|
|
|
|
|
|
|
|
The test environment used by the continuous integration system
|
|
|
|
is based on Docker and can be reproduced locally by using the
|
|
|
|
`.ci/run_tests.sh` script. Run with the --help switch to see
|
|
|
|
options.
|
|
|
|
|
2016-10-24 11:20:22 +02:00
|
|
|
## Postgres
|
2015-04-27 08:35:04 +02:00
|
|
|
|
2015-11-15 22:39:02 +01:00
|
|
|
Make sure that you have enabled building of postgres test in CMake.
|
2023-06-19 20:58:21 -04:00
|
|
|
`cmake -D ENABLE_TESTS=ON -D ENABLE_PGTEST=ON ..`
|
2015-11-15 22:39:02 +01:00
|
|
|
|
2021-10-05 17:59:27 +02:00
|
|
|
To test the postgres provider you will need to setup a test database
|
|
|
|
to which the postgres provider can connect.
|
2016-02-10 17:05:38 +01:00
|
|
|
|
2021-10-05 17:59:27 +02:00
|
|
|
By default the tests use the following connection string to access
|
|
|
|
the test database:
|
2016-02-10 17:05:38 +01:00
|
|
|
|
2017-06-02 18:31:27 +02:00
|
|
|
service=qgis_test
|
2015-11-15 22:39:02 +01:00
|
|
|
|
2017-06-02 18:31:27 +02:00
|
|
|
If these do not match your setup you can set the environment variable
|
|
|
|
`QGIS_PGTEST_DB` to the desired connection string. Note that you can
|
|
|
|
rely on standard libpq environment variables to tweak host, port user
|
|
|
|
and password (PGHOST, PGPORT, PGUSER, PGPASSWORD).
|
2015-11-15 22:39:02 +01:00
|
|
|
|
2021-10-05 17:59:27 +02:00
|
|
|
The test database must be initialized using the sql-scripts:
|
2016-02-10 17:05:38 +01:00
|
|
|
|
|
|
|
tests/testdata/provider/testdata_pg*.sql
|
|
|
|
|
2021-10-05 17:59:27 +02:00
|
|
|
They take care of activating PostGIS and creating some tables containing
|
|
|
|
test data.
|
2016-02-17 11:08:18 +01:00
|
|
|
|
|
|
|
For convenience, a shell script is provided to create the database
|
|
|
|
and initialize it as needed:
|
|
|
|
|
|
|
|
tests/testdata/provider/testdata_pg.sh
|
2016-10-24 11:20:22 +02:00
|
|
|
|
2021-10-05 17:59:27 +02:00
|
|
|
Some tests will attempt to create database users too and expect them to
|
|
|
|
be allowed to connect using a password.
|
|
|
|
Most PostgreSQL installation by default use "ident" authentication
|
|
|
|
model when connecting via unix sockets. Make sure the `qgis_test`
|
|
|
|
service (or your `QGIS_PGTEST_DB` connection string) uses a connection
|
|
|
|
method which allows passing username/password pair to connect (and
|
|
|
|
which allows creating users)
|
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
Some tests require a specific PostgreSQL server configuration
|
|
|
|
(installation of auth certificates) so the most convenient way
|
|
|
|
to bring up such server would be to (tweak $srcdir appropriately):
|
2016-10-24 11:20:22 +02:00
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
QGIS_WORKSPACE=${srcdir} \
|
2024-04-02 21:36:51 +00:00
|
|
|
docker compose -f .docker/docker-compose-testing-postgres.yml up -d postgres
|
2022-01-28 17:33:53 +01:00
|
|
|
export PGHOST=`docker inspect docker_postgres_1 | jq -r .[0].NetworkSettings.Networks.docker_default.IPAddress`
|
|
|
|
export PGUSER=docker
|
|
|
|
export PGPASSWORD=docker
|
|
|
|
tests/testdata/provider/testdata_pg.sh
|
|
|
|
echo "${PGHOST} postgres # for qgis_test, docker" | sudo tee -a /etc/hosts
|
2016-10-24 11:20:22 +02:00
|
|
|
|
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
# Running the tests
|
2016-10-24 11:43:36 +02:00
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
Once the test environment is setup, you can run all tests using `make check`.
|
|
|
|
Note you will need `xvfb-run` for that (sudo apt-get install xvfb).
|
2016-10-24 11:43:36 +02:00
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
Individual tests can be run using `ctest`.
|
2016-10-24 11:43:36 +02:00
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
For example if the output of `make check` ends like this:
|
2016-10-24 11:43:36 +02:00
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
```
|
|
|
|
The following tests FAILED:
|
2022-06-13 11:21:46 +02:00
|
|
|
77 - PyQgsFeature (Failed)
|
2022-01-28 17:33:53 +01:00
|
|
|
```
|
2016-10-24 11:43:36 +02:00
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
You could re-run the failing test with:
|
2017-01-20 12:23:23 +01:00
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
```
|
2022-06-13 11:21:46 +02:00
|
|
|
ctest -V -R PyQgsFeature
|
2022-01-28 17:33:53 +01:00
|
|
|
```
|
2017-01-20 12:23:23 +01:00
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
The parameter `-V` enables verbose mode and `-R` takes a regular expression as
|
|
|
|
parameter and will only run matching tests.
|
|
|
|
|
|
|
|
Note that the name of the test as reported by `make check` does not
|
|
|
|
always matches the name of the test as known by `cmake`.
|
|
|
|
When this happens, the `ctest -R <guessedName>` command will report
|
|
|
|
`No tests were found!!!` and you'll need to go hunting for the actual name.
|
|
|
|
A useful hunting tool is `git grep`, which could be used like this:
|
|
|
|
|
|
|
|
```
|
|
|
|
$ ctest -V -R testSslRequireNoCaCheck
|
|
|
|
No tests were found !!!
|
|
|
|
$ git grep testSslRequireNoCaCheck # Search for the reported testname
|
|
|
|
tests/src/python/test_authmanager_password_postgres.py: def testSslRequireNoCaCheck(self):
|
|
|
|
$ git grep test_authmanager_password_postgres # Search for the file containing the reported testname
|
|
|
|
tests/src/python/CMakeLists.txt: ADD_PYTHON_TEST(PyQgsAuthManagerPasswordPostgresTest test_authmanager_password_postgres.py)
|
|
|
|
$ ctest -V -R PyQgsAuthManagerPasswordPostgresTest # use the CMakeLists.txt name
|
|
|
|
```
|
|
|
|
|
2023-02-17 16:07:23 +01:00
|
|
|
You may also use `ctest -N` to get a list of test names according to
|
|
|
|
ctest.
|
|
|
|
|
2022-01-28 17:33:53 +01:00
|
|
|
If you get `Could not connect to any X display` errors it means that your build
|
|
|
|
machine does not have an X server. In that case you need to run the test under
|
|
|
|
`xvfb-run`. For example:
|
|
|
|
|
|
|
|
```
|
|
|
|
xvfb-run --server-args=-screen\ 0\ 1024x768x24 ctest -V -R PyQgsServerWMSGetMap
|
|
|
|
```
|
|
|
|
|
|
|
|
## Manually running python tests
|
|
|
|
|
|
|
|
For python tests, you can run a specific test inside a unit file
|
|
|
|
with something like this (tweak $builddir and $srcdir as appropriate)
|
|
|
|
|
|
|
|
```
|
|
|
|
QGIS_PREFIX_PATH=${builddir}/output PYTHONPATH=${builddir}/output/python:$PYTHONPATH \
|
|
|
|
python ${srcdir}/tests/src/python/test_qgsvectorfilewriter.py
|
|
|
|
TestQgsVectorLayer.testOverwriteLayer
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Running python tests in GDB
|
2017-01-20 12:23:23 +01:00
|
|
|
|
|
|
|
First find out the required environment variables by running the test outside
|
|
|
|
the debugger.
|
|
|
|
|
|
|
|
ctest -V -R ProcessingQgisAlgorithmsTest
|
|
|
|
|
|
|
|
Which prints for somewhere in the initialization code something like:
|
|
|
|
|
|
|
|
export LD_LIBRARY_PATH=NOTFOUND:/home/m-kuhn/dev/cpp/qgis/build-qt5/output/lib:
|
|
|
|
export PYTHONPATH=/home/m-kuhn/dev/cpp/qgis/build-qt5/output/python/:/home/m-kuhn/dev/cpp/qgis/build-qt5/output/python/plugins:/home/m-kuhn/dev/cpp/qgis/QGIS/tests/src/python:
|
|
|
|
|
|
|
|
First, run these two commands in the terminal.
|
|
|
|
|
|
|
|
On the following line it says something like:
|
|
|
|
|
|
|
|
-- Running /usr/bin/python3 /home/m-kuhn/dev/cpp/qgis/QGIS/python/plugins/processing/tests/QgisAlgorithmsTest.py
|
|
|
|
|
|
|
|
Which you can run in gdb with:
|
|
|
|
|
|
|
|
gdb -ex r --args /usr/bin/python3 /home/m-kuhn/dev/cpp/qgis/QGIS/python/plugins/processing/tests/QgisAlgorithmsTest.py
|
|
|
|
|
|
|
|
Now you can start using the usual gdb (`bt` etc.) interface or - if you have
|
|
|
|
installed the [appropriate debug tools (adjust for python3!)](https://wiki.python.org/moin/DebuggingWithGdb)
|
|
|
|
even allows doing python introspection (`py-bt`).
|
2022-01-28 17:33:53 +01:00
|
|
|
|
|
|
|
# Writing tests
|
|
|
|
|
|
|
|
Instructions about writing tests for the processing framework
|
|
|
|
can be found in a [separate README file](../python/plugins/processing/tests/README.md):
|
|
|
|
|
|
|
|
${TOP_SRCDIR}/python/plugins/processing/tests/README.md
|
|
|
|
|
|
|
|
Information about labeling tests design and organization:
|
|
|
|
|
|
|
|
${TOP_SRCDIR}/tests/testdata/labeling/README.rst
|
|
|
|
|
|
|
|
WCS testing information can be found in:
|
|
|
|
|
|
|
|
${TOP_SRCDIR}/tests/testdata/raster/README.WCS
|
|
|
|
|
|
|
|
About benchmark tests you can read:
|
|
|
|
|
|
|
|
${TOP_SRCDIR}/tests/bench/README
|
|
|
|
|
|
|
|
|