In addition to the code of the module itself, it is important to include a suite of tests. They guarantee that your add-on will remain functional when changes are applied to the code on which it depends. Once committed to GitHub, the unit tests are automatically run by the CI/CD pipeline every time the code in the repository is modified. Notifications are issued if a modification somehow affects your add-on.
The unit tests depend on the GRASS development package. It might already be installed on your system, but make it sure. On a packaged operating system like Ubuntu or Debian Linux this can be achieved with:
sudo apt install grass-devOr on Fedora/CentOS with:
sudo dnf install grass-develIf you have not done so yet, it is also helpful to install pre-commit. Follow the instructions in the main GRASS repository.
Unit tests must be stored in a subfolder named testsuite inside the add-on
folder. For example, if you contributed a raster module named r.mymodule you
would run:
cd src/raster/r.mymodule
mkdir testsuiteThen you can create a new Git branch and initiate a new unit test class:
git checkout new-branch
vim testsuite/test_mymodule.pyThe unit testing documentation in the GRASS Reference Manual provides an overview on how to create unit tests for C/C++ and Python code. Going through existing unit tests of a module like r.sun is also insightful.
In most circumstances you will wish to run the unit tests against a local version of the add-on that you recently modified or created. To do so you need to install this local version on your GRASS installation.
First start a new grass session. Does not matter on which location or mapset.
grass /home/user/GRASSDATA/location/mapsetThen use the flexibility of g.extension to install the add-on from the file
system.
g.extension r.mblend url=/home/user/git/grass-addons/src/raster/r.mymoduleYou can now run the unit tests from the GRASS session, for example:
python testsuite/test_mymodule.pyThe general contribution guidelines apply to unit tests. In case you are submitting a new add-on, the unit tests should feature in the pull request with the module itself. Otherwise submit the unit tests in a dedicated pull request to facilitate the work of the reviewers.