First of all, coverage isn't coverage. There're several coverage criteria, but most used are:
- Function coverage – Has each function (or subroutine) in the program been called?
- Statement coverage – Has each statement in the program been executed?
- Branch coverage – Has each branch (also called DD-path) of each control structure (such as in if and case statements) been executed? […]
- Condition coverage (or predicate coverage) – Has each Boolean sub-expression evaluated both to true and false?
However, whether coverage (in general) is a good measure is a quite controversial topic. For instance, Wei, Meyer, and Orial argue that—even on unit testing level—"branch coverage is not a good indicator for the effectiveness of a test suite." Whereas Gopinath and Ahmed state that it's a good predictor in the real world.
From my experience, I can say that it's helpful, although one should never rely solely on it. As I think Measuring code coverage in end-to-end tests? is related, consider the following answer by Sam Woods:
I always like to get code coverage for my functional tests, but not because I want to hit a certain percentage of code coverage. I like it because:
- It points me to areas of the code that are not covered.
- There are areas of the code that are very difficult to unit/integration test without having the entire system in place and doing end to end tests, so I like to compare the coverage from unit/integration tests to the coverage from my functional tests and see if there are things that should or could be covered in the end to end tests that may be more difficult in the earlier stages.
- I want to know which of my tests are equivalent, so I can look at what is covered by each test and see if there are tests I can eliminate or consolidate to be more efficient.
Regarding running these tests "once in a while, say, on a weekly basis": As already pointed out by alecxe, the observer effect is negligible for measuring coverage. Nowadays, one can safely include it in the continuous testing pipeline.