| 7 | | There are a few reasons for this. First, it would let `runtests` take into account the test tags when determining which app modules apply. Second, it would centralize the test label logic, which should simplify maintenance. (For example, I was previously unaware of this code path, which explains why some things mysteriously weren't working before.) Third, it might even permit test labels to be directory paths when used with `runtests.py`, as a free side effect. (Currently, directory paths don't seem to work with `runtests.py`, I believe for this reason.) |
| | 7 | There are a few reasons for this. First, it would let `runtests` take into account the test tags when determining which app modules apply. Second, it would centralize the test label logic, which should simplify maintenance. (For example, I was previously unaware of this code path, which explains why some things mysteriously weren't working before.) Third, it might even permit test labels to be directory paths when used with `runtests.py`, as a free side effect. (Currently, directory paths don't seem to work with `runtests.py`, I believe for this reason.) A fourth is that `runtests.py` will fail faster if a bad test label is passed. |