Here are the remaining components below thresholds, as of the last update of this task:
|----------------------+----------+------------| | repository | line (%) | branch (%) | |----------------------+----------+------------| | swh-web (frontend) | 71 | 52 |
Source: https://jenkins.softwareheritage.org/view/swh%20master/
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Migrated | gitlab-migration | T1411 reach a minimum of 80% SLOC coverage across all components | ||
| Migrated | gitlab-migration | T1219 add tests to git loader | ||
| Migrated | gitlab-migration | T1393 swh/loader/core/loader.py has no proper test coverage | ||
| Migrated | gitlab-migration | T1430 Add tests for the Debian loader | ||
| Migrated | gitlab-migration | T1431 Add tests for the Tar loader. | ||
| Migrated | gitlab-migration | T1439 loader-mercurial: Improve coverage | ||
| Migrated | gitlab-migration | T1768 Add end to end tests for the frontend part of swh-web | ||
| Migrated | gitlab-migration | T1769 Add unit tests for Javascript code | ||
| Migrated | gitlab-migration | T1770 Add end to end tests |
Tip: after running Tox in a repo, run coverage report -m to show which lines are not covered.
For the loader mercurial, there is a module swh.loader.mercurial.loader_verifier which is not production code.
It's there to test the loader manually, so that could either be probably moved to the tests and transformed into it or removed altogether.
The most recent update of the state of this task has shown a regression in the journal test coverage, which, per se, is not a big deal (just a few points). But it does raise the question of how, once we have attained whatever "minimum" coverage we are OK with, we monitor overtime that there is no regression. For instance, I think that code reviews should show to the reviewers how the submitted diff affects code coverage. Ideally, reviewers should be able to so if it has a net positive or negative effect on coverage, and take that into account in their review decisions. (Which is not to say we should never accept diffs that decrease code coverage—there might be reasons to do so. But it is a data point that would be useful for reviewers to see.)