8c8d48bb8f
This algorithm compares two vector layers, and determines which features are unchanged, added or deleted between the two. It is designed for comparing two different versions of the same dataset. When comparing features, the original and revised feature geometries will be compared against each other. Depending on the Geometry Comparison Behavior setting, the comparison will either be made using an exact comparison (where geometries must be an exact match for each other, including the order and count of vertices) or a topological comparison only (where are geometries area considered equal if all of the their component edges overlap. E.g. lines with the same vertex locations but opposite direction will be considered equal by this method). If the topological comparison is selected then any z or m values present in the geometries will not be compared. By default, the algorithm compares all attributes from the original and revised features. If the Attributes to Consider for Match parameter is changed, then only the selected attributes will be compared (e.g. allowing users to ignore a timestamp or ID field which is expected to change between the revisions). If any features in the original or revised layers do not have an associated geometry, then care must be taken to ensure that these features have a unique set of attributes selected for comparison. If this condition is not met, warnings will be raised and the resultant outputs may be misleading. The algorithm outputs three layers, one containing all features which are considered to be unchanged between the revisions, one containing features deleted from the original layer which are not present in the revised layer, and one containing features add to the revised layer which are not present in the original layer.
QGIS unit tests
Build tests
Make sure that you have enabled building of tests in CMake.
cmake -DENABLE_TESTS=ON ..
Run tests
You can run all tests using make check.
Note you will need xvfb-run for that (sudo apt-get install xvfb).
Individual tests can be run using ctest.
For example if the output of make check ends like this:
The following tests FAILED:
77 - PyQgsLocalServer (Failed)
You could re-run the failing test with:
ctest -V -R PyQgsLocalServer
The parameter -V enables verbose mode and -R takes a regular expression as
parameter and will only run matching tests.
For python tests, you can run a specific test inside a unit file with something like this:
QGIS_PREFIX_PATH=output PYTHONPATH=output/python:$PYTHONPATH \
python ${srcdir}/tests/src/python/test_qgsvectorfilewriter.py
TestQgsVectorLayer.testOverwriteLayer
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
Advanced configuration
Postgres
Make sure that you have enabled building of postgres test in CMake.
cmake -DENABLE_TESTS=ON -DENABLE_PGTEST=ON ..
To test the postgres provider you will need to have a database available to which the postgres provider can connect. The server will need to have PostGIS support enabled.
By default the tests use the following connection string:
service=qgis_test
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).
Please note that the test database needs to be initialized using the sql-scripts:
tests/testdata/provider/testdata_pg*.sql
They take care of activating PostGIS for the test database and create some tables containing test data.
For convenience, a shell script is provided to create the database and initialize it as needed:
tests/testdata/provider/testdata_pg.sh
Write tests
Instructions about writing tests for the processing framework can be found in a separate README file:
${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
Run python tests in GDB
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!)
even allows doing python introspection (py-bt).