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
By default the database schema/schemes containing the tests that were executed during the run, are fully reported by coverage reporter.
57
-
All valid unit tests are excluded from the report regardless if they were invoked or not. This way the coverage report is not affected by presence of tests and contains only the tested code.
55
+
### Coverage reporting options
56
+
57
+
There are two ways to gather code coverage.
58
+
- You can gather coverage for a particular database schema/schemes
59
+
- You can gather coverage on project files deployed to database as database objects (packages, functions, procedures ect.)
60
+
61
+
Those two options are mutually exclusive and should not be mixed. Depending on the parameters you pass you will be using one option or the other.
62
+
63
+
When using one of coverage reporters and no additional options are provided, coverage is gathered on a schema level.
64
+
The database schema/schemes containing the tests that were executed during the run, will be reported by coverage reporter.
65
+
66
+
All unit tests are excluded from the report regardless if they were invoked or not.
67
+
This way the coverage report is not affected by presence of tests and contains only the tested code.
58
68
59
69
The default behavior of coverage reporters can be altered, depending on your needs.
60
70
61
-
### Including/excluding objects in coverage reports
71
+
### Coverage on schema
72
+
73
+
#### Filtering objects in coverage reports
62
74
The most basic options are the include/exclude objects lists.
63
75
You may specify both include and exclude objects lists to specify which objects are to be included in the report and which are to be excluded.
64
76
Both of those options are meant to be used to narrow down the scope of unit test runs, that is broad by default.
@@ -77,11 +89,11 @@ Executes test `test_award_bonus` and gather on all objects in schema `ut3_user`
77
89
78
90
You can also combine the parameters and both will be applied.
79
91
80
-
### Defining different schema names
92
+
####Defining different schema names
81
93
In some architectures, you might end up in a situation, where your unit tests exist in a different schema than the tested code.
82
94
This is not the default or recommended approach but is supporter by utPLSQL.
83
95
In such scenarios, you would probably have a separate database schema to hold unit tests and a separate schema/schemes to hold the tested code.
84
-
Since by default, coverage reporting is done on the schema/schemes that the invoked tests are on, the code will not be included in coverage report as it is in a different schema than the invoked tests.
96
+
Since by default, coverage reporting is done on the schema/schemes that the invoked tests are on, the code will not be included in coverage report as it is in a different schema.
85
97
86
98
In this situation you need to provide list of schema names that the tested code is in. This option overrides the default schema names for coverage.
Executes test `test_award_bonus` in schema `ut3_user` and gather coverage for that execution on all non `unit-test` objects from schema `usr`.
93
105
94
106
You can combine schema names with include/exclude parameters and all will be applied.
95
-
The `a_coverage_schemes` parameter takes precedence however, so if include list contains objects from other schemes, that will not be considered.
107
+
Keep in mind that the if you use `a_include_list` the `a_coverage_schemes`will simply be ignored.
96
108
97
109
Example:
98
110
```sql
@@ -106,16 +118,21 @@ begin
106
118
);
107
119
end;
108
120
```
121
+
109
122
Executes test `test_award_bonus` in schema `ut3_user` and gather coverage for that execution on `award_bonus` object from schema `usr`. The exclude list is of no relevance as it is not overlapping with include list.
110
123
111
-
### Working with projects and project files
112
-
Both `sonar` and `coveralls` are utilities that are more project-oriented than database-centric. They report statistics and coverage for project files in version control system.
113
-
Nowadays, most of database projects are moving away from database-centric approach towards project/product-centric approach.
124
+
125
+
### Coverage on project
126
+
127
+
Both `Sonar` and `Coveralls` are utilities that are project-oriented and are not database-centric.
128
+
They report statistics and coverage for project files in version control system and are not aware of database at all.
114
129
Coverage reporting of utPLSQL allows you to perform code coverage analysis for your project files.
115
-
This feature is supported by all build-in coverage reporting formats.
130
+
utPLSQL is able to map code coverage from your database code to your project files.
116
131
132
+
When using project based approach, utPLSQL will report coverage only for project-files that were successfully mapped into database objects.
133
+
117
134
When using this invocation syntax, coverage is only reported for the provided files, so using project files as input for coverage is also a way of limiting the scope of coverage analysis.
118
-
This syntax also allows usage of `a_include_object_list` and `a_exclude_object_list` as optional parameters to filter the scope of analysis.
135
+
This syntax also allows usage of `a_exclude_object_list` as optional parameters to filter the scope of analysis based on database objects.
119
136
120
137
121
138
**Reporting using externally provided file mapping**
0 commit comments