Changes between Version 16 and Version 17 of GSoC/2014/TestingFrameworkForGRASS

Timestamp:

05/25/14 20:36:56 (11 years ago)

Author:

wenzeslaus

Comment:

note on documentation for tests

GSoC/2014/TestingFrameworkForGRASS

@@ -178 +178 @@
 Everything should go (primarily) to files and directories with some defined structure. Something would have to gather information from files and build some main pages and summary pages. The advantage of having everything in files is that it might be more robust and that it can easily run in parallel. However, gathering of information afterwards can be challenging. Files are really the only option how to integrate valgrind outputs.
 
-
 There is `TextTestRunner` in `unittest`, the implementation will start from there. For now, the testing framework will focus on HTML output. However, the goal is something like `GRASSTestRunner` which could do multiple outputs simultaneously (in the future) namely HTML, XML (there might be some reusable XML schemes for testing results) and TXT (might be enriched by some reStructuredText or Markdown or really plain). Some (simple) text (summary) should go in to standard output in parallel to output to files.
 
@@ -209 +208 @@
 A page for `testsuite` will be the "central" page of the report. There will be list (table) of all test scripts/modules, their `TestCase` classes, and their `test_` functions/methods with basic info and links to details. Considering amount of details there will be probably a separate page for each `test_` function/method.
 
-Details to one test (not all have to be implemented):
+Details for one test (not all have to be implemented):
 
  * standard output and standard error output of tests
@@ -220 +219 @@
   * it might be unclear what code to actually include (you can see names of modules, function, you know in which directory test suite was)
  * the testing code to see what exactly was tested and failed
- * pictures generated from maps for tests which were not successful (might be applied also to other types but this is really a bonus)
+ * documentation of testing method and `TestCase` class (extracted docstrings)
+ * related commit/revision number or ticket number
+  * in theory, each commit or closed ticket should have a test which proves that it works
+  * this can be part of test method (`test_*`) docstring and can be extracted by testing framework
+ * pictures generated from maps for tests which were not successful (might be applied also to other types but this all is really a bonus)
 
 Generally, the additional data can be linked or included directly (e.g. with some folding in HTML). This needs to be investigated.