utPLSQL / utPLSQL

Testing Framework for PL/SQL
https://www.utplsql.org/
Apache License 2.0
555 stars 184 forks source link

Case sensitive names #264

Open Pazus opened 7 years ago

Pazus commented 7 years ago

If a package has case-sensitive name (for example DWH."aQa") ut_suite_manager while scanning schema fails with an error when calling dbms_utility.name_resolve as we dont add ".

The problem might appead in other parts of the framework.

Case sensitiveness still has not to restrict a user input, I mean a user might execute a package with all lowercase and everything has to work correct. Bug needs deeper investigation

jgebal commented 7 years ago

@pazus, did you manage to get any progress on that issue?

CRACKISH commented 7 years ago

How are things going with fixing the error? :-)

jgebal commented 7 years ago

@pazus, do you think it will be feasible to get this fixed for 3.0.1?

Pazus commented 7 years ago

Not sure... still need to work on it

jgebal commented 5 years ago

New issue #920 opened on the same.

PhilippSalvisberg commented 5 years ago

Issue #920 was reduced to address the security issue. Support of quoted identifiers is required to fix this issue. Case-sensitivity is just one issue, special characters like spaces need the very same treatment. In some cases the quotes must be removed (e.g. for querying the data dictionary views) and in other cases they have to be kept (e.g. when calling a package). This requires significant change in the framework.

What is the real use case for this requirement? Why do we need to support quoted identifiers (case sensitive names) exactly?

jgebal commented 1 year ago

@PhilippSalvisberg I don't think there is real need to support unit tests with quoted identifiers. I do see however a potential for great simplification of package specification if we allow them.

Today, you need to do something like this:

create or replace package test_annot_disabled_reason as
  --%suite(annotations - disabled)
  --%suitepath(utplsql.ut3_tester.core.annotations)

  --%test(Disable all tests under the suite displaying suite level reason)
  procedure test_disable_on_suite_level;

  --%test(Disable all tests under one of two contexts displaying context level reason)
  procedure test_dis_on_1st_ctx_level;

  --%test(Disable a single tests from each of the contexts displaying test level reason)
  procedure test_disable_tests_level;

end;

While in fact you could do:

create or replace package "annotations - disabled" as
  --%suite
  --%suitepath(utplsql.ut3_tester.core.annotations)

  --%test
  procedure "Disable all tests under the suite displaying suite level reason";

  --%test
  procedure "Disable all tests under one of two contexts displaying context level reason";

  --%test
  procedure "Disable a single tests from each of the contexts displaying test level reason";

end;
PhilippSalvisberg commented 1 year ago

I like the idea.

It shows a flaw with descriptions of tests. The description and the name of the test procedure might be completely different (which is bad when looking for the procedure in the code). Using quoted identifiers for test procedures can eliminate some need for descriptions. However, when I use contexts I name the procedures with the context prefix and avoid the repetition of the context in the test description to make the test output more terse. So, I still see cases where the description and name of the test procedure do not match.

Nevertheless, this approach simplifies a lot of cases and that's good.