Context Navigation

TestingFrameworkForGRASS

-              v32
+              v33
 It is not clear if `valgrind` would be applied even for library tests. This would require to run the testing process with `valgrind`. But since it needs to run separately anyway, this can be done. In case we would like to run with `valgrind` test function (`test_*`), the testing framework would have to contain the `valgrind` running function anyway. The function would run the test function as subprocess (which is anyway necessary to deal with process termination). The advantage of integration into PyGRASS wouldn't be so big in this case. But even in the case of separate function for running subprocess, a PyGRASS `Module` class will be used to pass the parameters.
+Concerning static source code analysis, it seems that it is better to do it separately because it depends more on source code files or, in case of Python, modules and packages while tests seems to have their own structure. Also static source code analysis is not related to testing itself, although it is, for sure, part of quality assurance. However, it must be noted that some part of analysis can be one test case as suggested by [http://pep8.readthedocs.org/en/latest/advanced.html#automated-tests pep8 documentation] (test fails if code style requirements are not fulfilled). This could integrate `pep8` with testing framework in an elegant way but it would require each `testsuite` to explicitly request this check.
 === Dependencies ===