Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code coverage reports covered lines as missed lines #539

Closed
PhilippSalvisberg opened this Issue Dec 25, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@PhilippSalvisberg
Copy link
Member

PhilippSalvisberg commented Dec 25, 2017

Code coverage reports the following lines always as "not covered":

  • declaration of a private package variable/constant
  • END LOOP of a FOR-LOOP statement

These lines should be treated as irrelevant lines from my point of view. I've attached a coverage report to visualise the problem.

coverage.html.zip

@jgebal

This comment has been minimized.

Copy link
Member

jgebal commented Dec 25, 2017

Hi @PhilippSalvisberg
The filtering of badly reported coverage is achieved in those lines:

-- to avoid execution of regexp_like on every line

We do filter the end but it doesnt take into consideration labelled end loop statements:

For the package variables/constants - I did see them reported as positives (green) so not sure if we should disable it or try to disable it if it's reported as negative.

@jgebal

This comment has been minimized.

Copy link
Member

jgebal commented Dec 25, 2017

I don't think it's possible to recognize global variable/constant by just looking at a line of code from source.
Adding requirement on code to be compiled with PLScope enabled would be an overkill. I also fear of the performance hit for building coverage report, if we go with PLScope.
With 12.2 coverage things should be probably mych easier and better (hopefuly).
We might get 12.2 coverage running soon :)

@PhilippSalvisberg

This comment has been minimized.

Copy link
Member Author

PhilippSalvisberg commented Dec 25, 2017

Hi @jgebal ,

Thank you for the fast answer and super-fast fix for issue #540. Wow.

For the package variables/constants - I did see them reported as positives (green) so not sure if we should disable it or try to disable it if it's reported as negative.

I've prepared a small test using a private package constant and a private package variable. They are clearly used but reported as "missed lines". What is the case you've seen to work?

CREATE OR REPLACE PACKAGE pkg IS
   FUNCTION f1 RETURN BOOLEAN;
   FUNCTION f2 (p IN INTEGER) RETURN INTEGER;
END pkg;
/

CREATE OR REPLACE PACKAGE BODY pkg IS
   c CONSTANT BOOLEAN := TRUE;
   v INTEGER := 1;
   FUNCTION f1 RETURN BOOLEAN IS
   BEGIN
      RETURN c;
   END;
   FUNCTION f2 (p IN INTEGER) RETURN INTEGER IS
   BEGIN
      v := p;
      RETURN v;
   END;
END pkg;
/

CREATE OR REPLACE PACKAGE test_pkg IS
   -- %suite
   
   -- %test
   PROCEDURE f1;

   -- %test
   PROCEDURE f2;
END;
/

CREATE OR REPLACE PACKAGE BODY test_pkg IS
   PROCEDURE f1 IS
   BEGIN
      ut.expect(pkg.f1).to_equal(true);
   END;
   PROCEDURE f2 IS
   BEGIN
      ut.expect(pkg.f2(2)).to_equal(2);
   END;
END test_pkg;
/

SET SERVEROUTPUT ON
EXEC ut.run;

EXEC ut.run(ut_coverage_html_reporter());

coverage2.html.zip

@PhilippSalvisberg

This comment has been minimized.

Copy link
Member Author

PhilippSalvisberg commented Dec 26, 2017

Hi @jgebal ,

I've set up a project on Jenkins and generated the code coverage HTML file using the utPLSQL-cli. Worked like a charm. Most interesting was, that the reported coverage was 100% for each file (which is correct). I found out that calling dbms_session.reset_package before the ut_coverage_html_reporter was necessary for a consistent result, when calling tests multiple times in an Oracle session (see amended test at the end). Therefore some package persistent data must be responsible for the wrong/incomplete results.

So for me the problem is solved now.

I've tested also 12.2 Code Coverage and there are some strange results (similar to the ones of the PL/SQL Profiler). I had to do some postprocessing to get a correct result. So I do not think it will simplify your code coverage approach a lot. But the developers will get more control using the COVERAGE pragma to mark unfeasible code blocks. So it is still worth to support it.

Thank you.

CREATE OR REPLACE PACKAGE pkg IS
   FUNCTION f1 RETURN BOOLEAN;
   FUNCTION f2 (p IN INTEGER) RETURN INTEGER;
END pkg;
/

CREATE OR REPLACE PACKAGE BODY pkg IS
   c CONSTANT BOOLEAN := TRUE;
   v INTEGER := 1;
   FUNCTION f1 RETURN BOOLEAN IS
   BEGIN
      RETURN c;
   END;
   FUNCTION f2 (p IN INTEGER) RETURN INTEGER IS
   BEGIN
      v := p;
      RETURN v;
   END;
END pkg;
/

CREATE OR REPLACE PACKAGE test_pkg IS
   -- %suite

   -- %test
   PROCEDURE f1;

   -- %test
   PROCEDURE f2;
END;
/

CREATE OR REPLACE PACKAGE BODY test_pkg IS
   PROCEDURE f1 IS
   BEGIN
      ut.expect(pkg.f1).to_equal(true);
   END;
   PROCEDURE f2 IS
   BEGIN
      ut.expect(pkg.f2(2)).to_equal(2);
   END;
END test_pkg;
/

SET SERVEROUTPUT ON
EXEC ut.run;

SET FEEDBACK OFF
-- incomplete, wrong coverage result
SPOOL coverage_run1.html
EXEC ut.run(ut_coverage_html_reporter());
SPOOL OFF

EXEC dbms_session.reset_package;
SET SERVEROUTPUT ON
-- complete coverage result
SPOOL coverage_run2.html
EXEC ut.run(ut_coverage_html_reporter());
SPOOL OFF
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.