-
Notifications
You must be signed in to change notification settings - Fork 15
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
How to run "alter session set something" from the command line? #103
Comments
Hi @rafael-trevisan , One real-life example from my projects: create or replace package ut_testdata_helper as
procedure setup_session;
end;
/
create or replace package body ut_testdata_helper as
procedure setup_session
as
begin
DBMS_SESSION.set_nls('nls_date_format', '''MM/DD/SYYYY HH24:MI:SS''');
DBMS_SESSION.set_nls('NLS_TIMESTAMP_TZ_FORMAT', '''MM/DD/SYYYY HH24:MI:SS.FF TZH:TZM''');
DBMS_SESSION.set_nls('NLS_TIMESTAMP_FORMAT', '''MM/DD/SYYYY HH24:MI:SS.FF''');
DBMS_SESSION.set_nls('NLS_NUMERIC_CHARACTERS', '''.,''');
end;
end;
/
create or replace package ut_mytest as
-- %suite(My test-suite)
...
-- %beforeall
procedure setup;
end;
/
create or replace package body ut_mytest as
procedure setup
as
begin
ut_testdata_helper.setup_session();
end;
end;
/ @jgebal @Pazus Any thoughts on whether global setup/teardown scripting possibility would be beneficial to cli? |
If your tests share the same suitepath, you can benefit from defining this just once for whole set of test packages (suite) |
Hm, does this work with hierarchical suite-paths, too? create or replace package ut_main as
-- %suite(Main)
-- %suitepath(main)
-- %beforeall
procedure setup;
end;
/
create or replace package ut_sub as
-- %suite(Sub)
-- %suitepath(main.ut_main.my.sub)
-- %test
procedure my_test;
end;
/ |
package common is
--%suite
--%beforeall
procedure setup_sessionh
end;
package my_tests is
--%suite
--%suitepath(common)
....
end; |
Thank you for such a quick reply. What if I use Liquibase or Editions and I need to set the “version” I want to test. Let’s say I am using Editions and I have “release_v1” and “release_v2”. What’d be the best approach to switch between two or more releases? I mean, it’d be nice if I could test “release_v2” while other developers still work or even test “release_v1”. Should I have a suite-path for each release/edition and do my alter session there? Thx! |
Well, given this scenario, it would indeed be beneficial to have some basic support for executing some sort of I have no idea what we would be dealing with in terms of implementation cost. Would you be editioning your unit tests too? |
Yeah, I’ll try to make a Running tests through db is fine as I can put my Oracle allows to have more than one edition active. Unit tests are editionable as they need to reflect the changes in the code for that edition. This is my current work model. On the same database (but within my own schema) I can be working on “version 1.0” while other developers can be working on different versions on their own schemas (doing An unit test for v1.0 is certainly not the same for v2.0 as, let’s say, new methods were create to some pre-existing package, and the unit test “v2.0” needs to cover these new methods. Versioning and editioning unit tests is okay! Running tests through db is also okay! The only issue is to run using cli as I cannot set the edition I’m working on. Thx! |
I can see the benefit in having |
👍 for leaving that freedom to the user. |
I tried to use a |
Tried running with
|
Got it working through a schema logon trigger. For now, I'm going to set the latest edition as the current one when the user creates a new session. That'll allow proceeding with my work model. If we need to test some older version we can restore our database to that specific version. However, a |
From a security point of view: Should we only allow |
I’d vote to allow full-blown sql.
We should know and be responsible for what we’re doing.
… On Jul 15, 2019, at 8:10 AM, Samuel Nitsche ***@***.***> wrote:
From a security point of view: Should we only allow alter session statements here? Or allow full-blown sql?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I agree with @rafael-trevisan . Allow sql before and after of run test could be add more flexible way for run all suites. It would be nice to see it in the next release :) |
I see the need, especially with EBR it seems to be a very valuable feature |
Hi all,
Starting using utPLSLQ-cli here.
Is there a way to run a custom SQL command or script before running the tests from the command-line?
For i.e., I'd like to set a VPD calling some procedure in my db, but would be nice if the parameter for this procedure could be passed in the command-line somehow.
Thx
The text was updated successfully, but these errors were encountered: