Tracking it? Doesn't take too long to set up in some situations.
Increasing it? Depends on if that's trying to get to 100% or just to have a metric to see where tests are needed.
It's usually not productive to enforce it for long ongoing development projects (aside from maybe "stay about 70%" or something). It can be a neat metric, but I don't think it's very productive. Testing comes in the form over very unbalanced importance (see "Pareto distribution"). Start by testing the most important business critical functionality and then move out from there. 20% of your tests will cover 80% of your actual important use cases.
The trade off would be easier to manager if tests didn't require maintenance, but to get the best bang for your buck, focus on the most critical stuff first. Code coverage is by no means a necessity.
I was thinking about including the necessary instrumentation to check code coverage during regression tests. Something like coverage.py. The intent is not to get a specific number, but to understand which parts of the code might not be exercised enough by existing test cases.
Tracking it? Doesn't take too long to set up in some situations.
Increasing it? Depends on if that's trying to get to 100% or just to have a metric to see where tests are needed.
It's usually not productive to enforce it for long ongoing development projects (aside from maybe "stay about 70%" or something). It can be a neat metric, but I don't think it's very productive. Testing comes in the form over very unbalanced importance (see "Pareto distribution"). Start by testing the most important business critical functionality and then move out from there. 20% of your tests will cover 80% of your actual important use cases.
The trade off would be easier to manager if tests didn't require maintenance, but to get the best bang for your buck, focus on the most critical stuff first. Code coverage is by no means a necessity.