f63c302420
* [FEATURE] adds undo/redo for transaction groups [needs-docs] the undo/redo now works with transcation groups. Just check that there is no restriction in the transaction groups doc concerning undo. related to #14799 The undo/redo is implemented using SAVEPOINT. The QgsTransaction interface has been enlarged to allow savepoints creation and management. The savepoint is destroyed on rollbackToSavepoint to have the same behavior has the sql ROLLBACK TO SAVEPPOINT. To avoid the creation of a savepoint for each feature modified in bulk editing (e.g. paste, field calculator) the logic is a bit complicated: the savepoint is created on QgsVectorLayer::editCommandStarted and the first actual undo command (QgsVectorLayerUndoPassthroughCommand) is responsible for the re-creation of the savepoint in case of undo-redo. Since the behavior must be different in case edition doesn't take place inside an edit command, a member function has been added to QgsVectorLayer to expose the mEditCommandActive state. Another (commented) tricky bit is the modification of the database structure on add/delete attributes. On undo, the attribute is removed before the rollback to savepoint, i.e. there is a useless ALTER TABLE issued to restore the structure just before restoring it with the ROLLBACK TO SAVEPOINT. This is necessary to make the provider aware of the change of structure. It could be nicer/cleaner to have a way to reload providers metadata. The editPaste function has also been modified to use addFeatures instead of addFeature (plural/singular), this is at the expense of an additional "cpy" of the clipboard in memory, but it should improve perf with postgis provider. * fixup operator aliases
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 xfvb).
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
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 test uses one of the following connection string:
dbname=qgis_test
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).