E4 - Code coverage rework

[jgebal]

Target release or timeframe

No response

Scope and goals

Problem

Coverage reporting has known memory-consumption issues at scale.
Covered/uncovered line-level accuracy suffers due to flaky profiler data.
Test execution performance can be significantly affected by the use of profiler for gathering coverage data.
Profiler output is not always available, especially in cases when dbms_stats package is used.

Proposed direction

• Use 12.2-style coverage as the base data collection mechanism.
• Derive line coverage from other sources (e.g., PL/Scope, static identification of non-executable lines) instead of relying on profiler output.
• Add an option to scope coverage to tested code only, instead of defaulting to the whole schema.
• Change how data is handed over from coverage to prevent passing memory-intensive data to the reporters.

Depends on

#13 E3 - Annotations, suite structure & module rework

Issues Tracking

• PL/SQL source lines identified as not feasible are being reported in code coverage metrics utPLSQL#1341
• Flaky coverage report - wrongly reported uncovered lines when PL/SQL profiler reports 0 for total_time utPLSQL#1336
• Add the option to report coverage only on tested code utPLSQL#1371

Open questions for the community

No response