Changes between Version 34 and Version 35 of GSoC/2014/TestingFrameworkForGRASS

Timestamp:

06/04/14 20:46:05 (10 years ago)

Author:

wenzeslaus

Comment:

list of static analysis tools for Python

GSoC/2014/TestingFrameworkForGRASS

@@ -234 +234 @@
 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.
 
+For the static analysis of Python code, there is several tools commonly (i.e. in repositories of Linux distributions) available, most notably pep8, Pylint, and Flake8. Table of tools and their features (June 2014):
+
+|| tool || focus || HTML report || imports modules ||
+|| [https://pypi.python.org/pypi/pep8 pep8] || style ([http://legacy.python.org/dev/peps/pep-0008/ PEP8]) || no || no ||
+|| [http://www.pylint.org/ Pylint] || errors and style || yes || [http://docs.pylint.org/faq.html#why-does-pychecker-catch-problems-with-imports-that-pylint-doesn-t no] ||
+|| [http://pychecker.sourceforge.net/ PyChecker] || errors || || yes ||
+|| [https://pypi.python.org/pypi/pyflakes PyFlakes] || errors || || ||
+|| [https://pypi.python.org/pypi/mccabe McCabe complexity checker] || code [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] || ||
+|| [https://pypi.python.org/pypi/flake8 Flake8] || combines !PyFlakes, pep8, and mccabe || yes || ||
+
 The determining code coverage of the tests must be done during testing. Speaking about Python, some more advanced testing frameworks includes code coverage tools in them, namely [http://nedbatchelder.com/code/coverage/ coverage]. Since `unittest` does not include `coverage`, GRASS will have to incorporate `coverage` into its testing framework. The basic usage is rather simple. If we consider that all is running in one Python process, we can just put the following (rather messy) code into some module which will be loaded before the tests will start (the main invoking script would be of course the best place):
 {{{