Changes between Version 24 and Version 25 of GSoC/2014/TestingFrameworkForGRASS

Timestamp:

05/30/14 11:30:05 (11 years ago)

Author:

wenzeslaus

Comment:

example for test discovery

GSoC/2014/TestingFrameworkForGRASS

@@ -138 +138 @@
 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).
+`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`.
 
 {{{
@@ -153 +153 @@
 cd lib/python/temporal(/testsuite)
 python .../gunittest/grass_main_test_runner.py unittests_register.TestRegisterFunctions.test_absolute_time_strds_2
+}}}
+
+An 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).
+
+{{{
+# invoke test module/script using test discovery but run only one module/script
+python .../gunittest/grass_main_test_runner.py discover -s lib/python/temporal/ -p unittests_register.py
 }}}
 === Dealing with process termination ===