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.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
utPLSQL comes with a built-in coverage reporting engine. The code coverage reporting uses DBMS_PROFILER package provided with Oracle database.
4
+
utPLSQL comes with a built-in coverage reporting engine. The code coverage reporting uses package DBMS_PROFILER (and DBMS_PLSQL_CODE_COVERAGE on Oracle database version 12.2 and above) provided with Oracle database.
5
5
Code coverage is gathered for the following source types:
6
6
* package bodies
7
7
* type bodies
@@ -15,7 +15,7 @@ Code coverage is gathered for the following source types:
15
15
16
16
To obtain information about code coverage for unit tests, run utPLSQL with one of built-in code coverage reporters.
17
17
The following code coverage reporters are supplied with utPLSQL:
18
-
*`ut_coverage_html_reporter` - generates a HTML coverage report providing summary and detailed information on code coverage. The HTML reporter is based on the open-source [simplecov-html](https://github.com/colszowka/simplecov-html) reporter for Ruby. It includes source code of the code that was covered (if possible)
18
+
*`ut_coverage_html_reporter` - generates a HTML coverage report providing summary and detailed information on code coverage. The HTML reporter is based on the open-source [simplecov-html](https://github.com/colszowka/simplecov-html) reporter for Ruby. It includes source code of the code that was covered (if the code is accessible for test user)
19
19
*`ut_coveralls_reporter` - generates a [Coveralls compatible JSON](https://coveralls.zendesk.com/hc/en-us/articles/201774865-API-Introduction) coverage report providing detailed information on code coverage with line numbers. This coverage report is designed to be consumed by cloud services like [Coveralls](https://coveralls.io)
20
20
*`ut_coverage_sonar_reporter` - generates a [Sonar Compatible XML](https://docs.sonarqube.org/latest/analysis/generic-test/) coverage report providing detailed information on code coverage with line numbers. This coverage report is designed to be consumed by services like [SonarQube](https://www.sonarqube.org/) and [SonarCloud](https://about.sonarcloud.io/)
21
21
*`ut_coverage_cobertura_reporter` - generates a basic Cobertura coverage (http://cobertura.sourceforge.net/xml/coverage-04.dtd) report providing detailed information on code coverage with line numbers. This coverage report is designed to be consumed by services like TFS and Jenkins. Check this link for an example of XML generated by Java: https://raw.githubusercontent.com/jenkinsci/cobertura-plugin/master/src/test/resources/hudson/plugins/cobertura/coverage-with-data.xml
@@ -30,7 +30,7 @@ In order to be able to gather coverage information, the user executing unit test
30
30
31
31
If you have `execute` privilege on the code that is being tested, but do not have `create any procedure` system privilege, then the code that is being tested will be reported as not covered (coverage = 0%).
32
32
If you have `execute` privilege only on the unit tests, but do not have `execute` privilege on the code that is being tested, the code will not be reported by coverage - as if it did not exist in the database.
33
-
If the code that is being tested is complied as NATIVE, the code coverage will not be reported as well.
33
+
If the code that is being tested is compiled as NATIVE, the code coverage will not be reported as well.
34
34
35
35
## Running unit tests with coverage
36
36
Using the code coverage functionality is as easy as using any other [reporter](reporters.md) for the utPLSQL test-run. You just run your tests from your preferred SQL tool and save the reporter results to a file.
@@ -65,6 +65,7 @@ Due to security model of `dbms_plsql_code_coverage` package, utPLSQL grants acce
65
65
The access and synonyms will be public when using the headless installation. This approach avoids complexity of forcing every user of utPLSQL framework to create tables on their own.
There are six options that can be used to narrow down the scope of coverage report:
132
-
-`a_include_objects` - list of `[object_owner.].object_name` to be included in the coverage report.
133
-
-`a_exclude_objects` - list of `[object_owner.].object_name` to be excluded from the coverage report
134
-
-`a_include_schema_expr` - string of regex expression of schemas to be included in the coverage report. It will override `a_include_objects` for example :
Will result in showing coverage for all schemas that match regular expression `^ut3_develop`and ignore objectes defined by parameter `a_include_objects`
140
-
141
-
-`a_include_object_expr`- string of regex expression of objects ( no schema names included ) to be included in the coverage report. It will override `a_include_objects` for example:
Will result in showing coverage for all objects that name match regular expression `regex123`and ignore objectes defined by parameter `a_include_objects`
147
-
148
-
-`a_exclude_schema_expr`- string of regex expression of schemas to be excluded from the coverage report. It will override `a_exclude_objects` for example:
Will result in showing coverage for all objects that schema is not matching regular expression `^ut3_tester`and ignore exclusion defined by parameter `a_exclude_objects`
154
-
155
-
-`a_exclude_object_expr`- string of regex expression of objects to be excluded from the coverage report. It will override `a_exclude_objects` for example
Will result in showing coverage for all objects that name is not matching regular expression `regex123`and ignore exclusion defined by parameter `a_exclude_objects`
161
-
132
+
There are multiple parameters that can be used to define the scope of coverage report:
133
+
-`a_source_file_mappings ( ut_file_mappings )` - map of filenames to database objects. It is used for file-based coverage - see below.
134
+
-`a_include_schema_expr ( varchar(4000) )` - string of regex expression of schemas to be included in the coverage report.
135
+
-`a_include_object_expr ( varchar(4000) )` - string of regex expression of objects ( without schema name ) to be included in the coverage report.
136
+
-`a_exclude_schema_expr ( varchar(4000) )` - string of regex expression of schemas to be excluded from the coverage report.
137
+
-`a_exclude_object_expr ( varchar(4000) )` - string of regex expression of objects to be excluded from the coverage report.
138
+
-`a_coverage_schemes ( ut_varchar2_list )` - List of database schema names to gather coverage on.
139
+
-`a_include_objects ( ut_varchar2_list )` - list of `[object_owner.]object_name` to be included in the coverage report.
140
+
-`a_exclude_objects ( ut_varchar2_list )` - list of `[object_owner.]object_name` to be excluded from the coverage report.
162
141
163
142
You may specify both _include_ and _exclude_ options to gain more control over what needs to be included / excluded from the coverage report.
164
143
165
-
The object owner is optional in the object list.
166
-
If you do not provide an object owner, the _include_/_exclude_ list will be considered for every schema used for coverage gathering (as described above).
144
+
**Important notes**
145
+
The order of priority is for evaluation of include/exclude filter parameters is as follows.
146
+
- if `a_source_file_mappings` is defined then all include/exclude parameters are ignored (see section below for usage of `a_source_file_mappings` parameter )
147
+
- else if `a_include_schema_expr` or `a_include_object_expr` parameter is specified then parameters `a_coverage_schemes` and `a_include_objects` are ignored
148
+
- else if `a_include_objects` is specified then the coverage is gathered only on specified database objects.
149
+
- if `a_coverage_schemes` is specified then those schemas are used for objects in `a_include_objects` without schema name
150
+
- if `a_coverage_schemes` is not specified then schema from paths (`a_paths`) parameter are used for objects in `a_include_objects` without schema name
151
+
- else if, only the `a_coverage_schemes` is specified then the coverage is gathered only on specified database schemas
152
+
- else if no coverage specific parameters are provided coverage is gathered on all schemas specified in paths passed to run procedure
153
+
- else if no paths were specified, the coverage is gathered on current schema of the session running the tests
Will result in showing coverage for all objects that name is not matching regular expression `regex123`.
204
+
Will ignore exclusion defined by parameter `a_exclude_objects`.
205
+
167
206
168
207
Example: Limiting coverage by object name, for tested code located in the same schema as the unit tests.
169
208
```sql
@@ -214,7 +253,8 @@ Executes test `test_award_bonus` in schema `unit_test_schema`. Coverage will be
214
253
215
254
**Note**
216
255
> When running coverage on schema objects, all source code of package bodies, functions, procedures, type bodies and triggers that were not executed will be reported as having 0% code coverage and all source code lines will show as uncovered.
217
-
> This is different than the behavior when gathering coverage on project files.
256
+
> This is different from the behavior when gathering coverage on project files.
257
+
218
258
219
259
### Project based Coverage
220
260
@@ -687,7 +727,7 @@ begin
687
727
end;
688
728
```
689
729
690
-
## Reporting coverage outside of utPLSQL
730
+
## Reporting coverage outside utPLSQL and in parallel sessions
691
731
692
732
utPSLQL allows fo standalone reporting code coverage across multiple database sessions. This functionality enables coverage reporting for external testing tools.
693
733
@@ -811,9 +851,3 @@ If the identifier is not unique, previous runs of coverage that used the same `c
811
851
For details on the meaning of `schema_names`, `exclude_objects`, `include_objects`, `file_mappings` see sections above.
812
852
Note that data-types of include/exclude/schema lists are different when calling `ut.run` vs. calling `get_report/get_report_cursor`.
813
853
814
-
The order of priority is for evaluation of include/exclude is as follows.
815
-
- if `file_mappings` is specified then all include/exclude parameters are ignored
816
-
- else if `..._expr` is specified then include_objects/exclude_objects parameters are ignored
817
-
- else if `schema_names` is specified then the coverage is gathered on all object of specified schemas
818
-
- else coverage is gathered on all schemas specified in paths passed to run procedure
819
-
- if no paths were specified, the coverage is gathered on current schema of the session running the tests
0 commit comments