Changes between Version 22 and Version 23 of GSoC/2014/TestingFrameworkForGRASS

Timestamp:

May 30, 2014, 7:51:36 AM (10 years ago)

Author:

wenzeslaus

Comment:

importing and running modules: using unittest

GSoC/2014/TestingFrameworkForGRASS

@@ -132 +132 @@
 Compared to suggestion in ticket:2105#comment:4 it does not solve everything in `test_module` (`run_module`) function but it uses `self.assert*` similarly to `unittest.TestCase` which (syntactically) allows to check more then one thing. 
 
-=== Test script should be importable ===
-
-Test scripts must have module/package character (as unittests requires for test discovery). This applies for both unittests and doctests, no exceptions. To have the possibility of import, all the GRASS Python libraries shouldn't do anything fancy at import time. For example, doctests currently don't work with `grass.script` unless you call [source:grass/trunk/gui/wxpython/core/toolboxes.py?rev=60218#L630 a set of functions] to deal with function `_` (underscore) because of installing translate function as buildin `_` function while `_` function is used also in `doctest`. (This is fixed for GUI but still applies to Python libraries.)
+=== Finding and running the test modules ===
+
+Test modules/scripts must have module/package character. This applies for both unittests and doctests, no exceptions. To have the possibility of import, all the GRASS Python libraries shouldn't do anything fancy at import time. For example, doctests currently don't work with `grass.script` unless you call [source:grass/trunk/gui/wxpython/core/toolboxes.py?rev=60218#L630 a set of functions] to deal with function `_` (underscore) because of installing translate function as buildin `_` function while `_` function is used also in `doctest`. (This is fixed for GUI but still applies to Python libraries.)
 
 Doctests (inside normal module code, in separate documentation, or doctests created just for the purpose of testing, see [https://docs.python.org/2/library/doctest.html#soapbox explanation of different doctest use cases]) will be wrapped as `unittest` test cases (in the `testsuite` directory). There is a [https://docs.python.org/2/library/doctest.html#unittest-api standard way] to do it. Everything requires the possibility to import safely (without side effects).
+
+`unittest` default implementation expects tests to not only by importable but really on path, so we would need to add the tested module on path beforehand in case we will use the classes as they are. In theory, it should be enough to add the directory containing file to the `sys.path`. This would add the advantage of invoking even separate test methods (`testmodule.TestCase.test_method`). It seems that simple `sys.path.insert(0, '.')` (if we are in directory with the test) and than import with name of the module works. On the other hand, the test discovery does much more tricks to get everything right, so it might be more robust than just adding directory to `sys.path`. The alternative is to use test discovery even for cases when we know what we are looking for. The most easy way how to run tests in one file would be to use test discovery with a file name as pattern and file path as search directory (which limits the discovery just the one particular file). The disadvantage is that it is not possible to run individual test methods (as in the case of direct imports from path).
+
+{{{
+#!python
+# file: gunittest/grass_main_test_runner.py
+from main import main
+sys.path.insert(0, '.')
+main()
+# simplified)
+}}}
+
+{{{
+# run only one particular test method
+cd lib/python/temporal(/testsuite)
+python .../gunittest/grass_main_test_runner.py unittests_register.TestRegisterFunctions.test_absolute_time_strds_2
+}}}
 === Dealing with process termination ===