| | 185 | The structure of report will be based on the source code structure (something can be separate pages, something just page content): |
| | 186 | |
| | 187 | * `lib` |
| | 188 | * `gis` |
| | 189 | * `gmath` |
| | 190 | * ... (other libraries) |
| | 191 | * `raster` |
| | 192 | * `r.slope.aspect` |
| | 193 | * ... (other modules) |
| | 194 | * `vector` |
| | 195 | * `v.edit` (`testsuite` directory is at this level) |
| | 196 | * test script/module |
| | 197 | * `TestCase` class |
| | 198 | * `test_` function/method |
| | 199 | * standard output |
| | 200 | * error output |
| | 201 | * ... (other details) |
| | 202 | |
| | 203 | There will be (at least one) top level summary page with percentages and links to subsections. |
| | 204 | |
| | 205 | It is not clear how to deal with libraries with subdirectories (such as `lib/vector/vedit/`) and groups of modules (such as `raster/simwe/`). Will each module have separate tests? Will the common library be tested (by programs/modules in case of C/C++, by standard tests in case of Python)? The rule of thumb would be to put all directories with `testsuite` directory on the same level. This is robust for any level of nesting and for directories having `testsuite` directory together with subdirectories having their own `testsuite` directories. In this system, a `testsuite` directory would be the only element and its attribute is the original directory in the code where it was discovered. Any higher level pages in report would have reconstruct the structure from these attributes. The advantage is that we can introduce different reconstructions with different simplifications, for example we can have `lib` (except for `lib/python`), `lib/python`, `vector`, etc. or we can have just everything on the same level, or just a selection (raster modules or everything useful for vectors from `lib`, `lib/python` and both raster and vector modules). |
| | 206 | |
| | 207 | We can introduce a rule that each test script/module can contain only one `TestCase` class which would simplify the tree. However, this is probably not needed because both the implementation and the representation can deal with this easily. |
| | 208 | |
| | 209 | 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. |
| | 210 | |
