Created by: portnov
General testing facility description for developers
Automated tests are implemented by usage of standard Python's unittest
module (https://docs.python.org/3/library/unittest.html).
In sverchok.utils.testing
module there is a number of utility methods and some base classes for test cases.
Test cases themselves are under tests/
directory. The files have to be named *_tests.py
.
Test data files are located under tests/references/
directory. There are .blend.gz
and .json
files used as patterns/references for comparison.
Test cases can be run in two ways:
- From running Blender. For this you have to enable "Developer mode" under Sverchok addon preferences. Then in Sverchok's N panel you will see Testing panel and a button "Run all tests" in it.
- From command line. There is script named
run_tests.sh
in root directory (this is for bash, I imagine anyone familiar with Windows'scmd.exe
/ Powershell scripting can easily write similar script for Windows). If your blender executable is not available as simpleblender
command, you have to pass it in the command line, likeBLENDER=~/soft/blender-2.79-linux-glibc219-x86_64/blender ./run_tests.sh
.
Testing plan
- For right now I feel necessity to test JSON export/import code. But after this PR is merged, everyone is welcome to write tests for everything: nodes, utility functions, ...
- Export testing.
-
Exporting of single simple nodes. The simplest approach is to programmatically create nodes, export them and compare resulting JSON to expected. We need to have at least one test per each supported property type (so I'm guessing about ~5 such tests for starters): - IntProperty
- FloatProperty
- BoolProperty
- EnumProperty
-
Exporting simple complex nodes (Monad, Script and so on). For now I'm going to use the same approach for testing. But, it is too complicated to create such nodes programmatically. Instead, I'm going to link the whole node tree from specially prepared .blend file. This group should have at least 1 test per each complex node class. -
Exporting trees with links. The same approach as for single complex nodes. There should be at least 1 such test for starters, and then we can add more complicated tests gradually.
-
- Import testing:
-
For simple nodes, it is possible to write generic comparing function. So: create a node programmatically, load another node from JSON, compare two nodes. Again we need ~1 test per supported property type. -
For complex nodes or complete node trees, it will take too much effort to write generic comparing function. So: link a tree from reference .blend file, load another tree from JSON, then compare certain subset of settings of two trees. And then improve this test gradually. We need at least 1 such test per complex node class, plus at least 1 test for complete tree.
-