Closed jgebal closed 5 years ago
I did a bit of debug on utPLSQL itself to capture what is passed from cli. Here are the outputs from invocations:
utPLSQL-cli v3.1.7
a_file_paths <UT_VARCHAR2_LIST>
<VARCHAR2>source\api\be_between.syn</VARCHAR2>
<VARCHAR2>source\api\be_empty.syn</VARCHAR2>
...
<VARCHAR2>source\uninstall_objects.sql</VARCHAR2>
<VARCHAR2>source\uninstall_synonyms.sql</VARCHAR2>
</UT_VARCHAR2_LIST>
a_file_to_object_type_mapping <UT_KEY_VALUE_PAIRS/>
l_file_to_object_type_mapping <UT_KEY_VALUE_PAIRS/>
a_regex_pattern=
a_object_owner_subexpression=
a_object_name_subexpression=
a_object_type_subexpression=
a_file_paths <UT_VARCHAR2_LIST>
<VARCHAR2>test\common_helper\utplsql.pkb</VARCHAR2>
<VARCHAR2>test\common_helper\utplsql.pks</VARCHAR2>
...
<VARCHAR2>test\ut3_user\test_user.pkb</VARCHAR2>
<VARCHAR2>test\ut3_user\test_user.pks</VARCHAR2>
</UT_VARCHAR2_LIST>
a_file_to_object_type_mapping <UT_KEY_VALUE_PAIRS/>
l_file_to_object_type_mapping <UT_KEY_VALUE_PAIRS/>
a_regex_pattern=
a_object_owner_subexpression=
a_object_name_subexpression=
a_object_type_subexpression=
utPLSQL-cli v3.1.6
a_file_paths <UT_VARCHAR2_LIST>
<VARCHAR2>source\api\be_between.syn</VARCHAR2>
<VARCHAR2>source\api\be_empty.syn</VARCHAR2>
...
<VARCHAR2>source\uninstall_objects.sql</VARCHAR2>
<VARCHAR2>source\uninstall_synonyms.sql</VARCHAR2>
</UT_VARCHAR2_LIST>
a_file_to_object_type_mapping
l_file_to_object_type_mapping <UT_KEY_VALUE_PAIRS>
<UT_KEY_VALUE_PAIR>
<KEY>fnc</KEY>
<VALUE>FUNCTION</VALUE>
</UT_KEY_VALUE_PAIR>
<UT_KEY_VALUE_PAIR>
<KEY>prc</KEY>
<VALUE>PROCEDURE</VALUE>
</UT_KEY_VALUE_PAIR>
<UT_KEY_VALUE_PAIR>
<KEY>tpb</KEY>
<VALUE>TYPE BODY</VALUE>
</UT_KEY_VALUE_PAIR>
<UT_KEY_VALUE_PAIR>
<KEY>pkb</KEY>
<VALUE>PACKAGE BODY</VALUE>
</UT_KEY_VALUE_PAIR>
<UT_KEY_VALUE_PAIR>
<KEY>bdy</KEY>
<VALUE>PACKAGE BODY</VALUE>
</UT_KEY_VALUE_PAIR>
<UT_KEY_VALUE_PAIR>
<KEY>trg</KEY>
<VALUE>TRIGGER</VALUE>
</UT_KEY_VALUE_PAIR>
</UT_KEY_VALUE_PAIRS>
a_regex_pattern=
a_object_owner_subexpression=
a_object_name_subexpression=
a_object_type_subexpression=
a_file_paths <UT_VARCHAR2_LIST>
<VARCHAR2>test\common_helper\utplsql.pkb</VARCHAR2>
<VARCHAR2>test\common_helper\utplsql.pks</VARCHAR2>
...
<VARCHAR2>test\ut3_user\test_user.pkb</VARCHAR2>
<VARCHAR2>test\ut3_user\test_user.pks</VARCHAR2>
</UT_VARCHAR2_LIST>
a_file_to_object_type_mapping
l_file_to_object_type_mapping <UT_KEY_VALUE_PAIRS>
<UT_KEY_VALUE_PAIR>
<KEY>fnc</KEY>
<VALUE>FUNCTION</VALUE>
</UT_KEY_VALUE_PAIR>
<UT_KEY_VALUE_PAIR>
<KEY>prc</KEY>
<VALUE>PROCEDURE</VALUE>
</UT_KEY_VALUE_PAIR>
<UT_KEY_VALUE_PAIR>
<KEY>tpb</KEY>
<VALUE>TYPE BODY</VALUE>
</UT_KEY_VALUE_PAIR>
<UT_KEY_VALUE_PAIR>
<KEY>pkb</KEY>
<VALUE>PACKAGE BODY</VALUE>
</UT_KEY_VALUE_PAIR>
<UT_KEY_VALUE_PAIR>
<KEY>bdy</KEY>
<VALUE>PACKAGE BODY</VALUE>
</UT_KEY_VALUE_PAIR>
<UT_KEY_VALUE_PAIR>
<KEY>trg</KEY>
<VALUE>TRIGGER</VALUE>
</UT_KEY_VALUE_PAIR>
</UT_KEY_VALUE_PAIRS>
a_regex_pattern=
a_object_owner_subexpression=
a_object_name_subexpression=
a_object_type_subexpression=
It seems that in 3.1.7, the parameter a_file_to_object_type_mapping
is passed as empty array.
utPLSQL-core is using default object_type mapping when the passed argument is null
.
Since empty array is not a valid value, we could treat empty array the same way we treat null and replace it with default mapping in utPLSQL-core. This doesn't change the fact that for backward compatibility utPLSQL-cli needs to be fixed.
Okay, got it - we call it now as empty array but should pass as null when not set. That somewhat contradicts my goals to become more immutable 🤪
Question: Is an empty mapping array ever a valid option? I don't think so but would be sure. If not, I'll handle this in the api, so we don't rely on any client to distinguish between empty/null.
Empty array is not a valid input as it will never cause a proper mapping. Null/missing parameter is identified as "use defaults" directive for framework, just like with many other parameters.
While trying new build pipeline with Azure on out uPLSQL-demo-project, I've decided to switch to latest utPLSQL-cli. It was then, when I've noticed that coverage is not getting reported on project files.
At first I thought that it's related to build configuration itself but after a bit of unsuccessful debugging I've decided to switch to utPLSQL-cli v3.1.6
On utPLSQL-cli v 3.1.6 coverage is generated without issues.
The reason for missing coverage is missing/invalid files mapping.
Seems like regression in v3.1.7.
Worth noting is that utPLSQL-core is using files-mapping to narrow the scope of coverage. When file names are passed in incorrect form, the result of mapping will be empty.
I suspect that either:
The difference in behavior can be seen here:
test_results.xml
contains DB object_name as file_name.test_results.xml
contains expected file_names.