PL/SQL source lines identified as not feasible are being reported in code coverage metrics

[markhawker76]

Hi,

When I am using the HTML code coverage reporter, I am getting PL/SQL source lines included in the code coverage metrics even though they have been excluded with the compile pragma COVERAGE using arguments 'NOT_FEASIBLE', 'NOT_FEASIBLE_START' or 'NOT_FEASIBLE_END'.

Please could you confirm whether this is expected behaviour or not. If expected, is there another way to exclude these lines of course (apart from removing them completely :-) )

Kind regards,
Mark.

[lwasylow]

Hi @markhawker76
The functionality you describing is a feature of dbms coverage which we don't use fully.
We are mainly using profiler and running dbms coverage as supplemental data.
We could think about running one or the other only as an option but the block coverage is not entirely accurate and have provided us with very interesting results.
I will investigate if using a pragmatyk Not feasible generate some data that we could use the exclude from current.
If not and lines are not recorded anywhere with some flag than I'm afraid its not possible.

[markhawker76]

Hi,

Thanks for replying quickly.

I looked into the information provided by the SYS.DBMS_CODE_COVERAGE package when reporting on a run. I can confirm that the information populated in DBMSPCC_BLOCKS appears to be correct when using the coverage compiler pragma. However I do see the issue, as there is no easy way of identifying executable code within that block (or series of blocks using 'NOT_FEASIBLE_[START|END]' arguments.

Many thanks,
Mark.

[jgebal]

It would need to be investigated and developed as an enhancement.
I'm pretty sure it can be done but would require some decent testing and experimenting to make sure that it behaves correctly.

What vestion of DB are you using?

[markhawker76]

Hi,

I am using Oracle 21c EE with the latest patch set.

I searched and found an interesting article from Chris Saxon regarding code coverage using line numbers rather than “execution blocks”. He thought that code coverage by line numbers alone could give false positives — especially if you have the following code scenario:

IF func_a() OR func_b()
THEN …

Here there are two execution blocks that may or may not be executed due to short-circuit evaluation. Chris seemed to suggest a line-based coverage could falsely report coverage of “func_b()”, whereas the output of Oracle’s code coverage tools would yield a more accurate outcome.

I guess the hard part would be interpreting the data provided by the database into a format a developer can readily understand. If there were a way of representing both line numbers and execution blocks at the same time, perhaps the Oracle code coverage data (if accurate), would be the way to go.

Sign me up for helping to test if the utPLSQL team believe it is worth pursuing.

Kind regards,
Mark.

[jgebal]

Hi @markhawker76
utPLSQL is combining plsql_profiler and dbms_plsql_code_coverage to provide line coverage with statement level coverage.

That way, if only part of the PL/SQL line was covered, it will be indicated in the report.

This provides best possible coverage information we can give.
So you can have line coverage and also statement coverage see documentation here and some example here