Skip to content
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

Internal variable that stores test case name #781

Closed
MS-24 opened this issue Nov 9, 2018 · 7 comments · Fixed by #963
Closed

Internal variable that stores test case name #781

MS-24 opened this issue Nov 9, 2018 · 7 comments · Fixed by #963

Comments

@MS-24
Copy link

MS-24 commented Nov 9, 2018

Hi there ,

I would like to if there is any internal variable that stores the test case name in it , so that I could use this in my --%beforetest annotation , to handle input data.

Thanks!!

@lwasylow
Copy link
Member

lwasylow commented Nov 9, 2018

Hi
Can you clarify what you mean ?
If you could let us know what at are your trying to achieve , so sample scenario/ mockup ?

@MS-24
Copy link
Author

MS-24 commented Nov 9, 2018

Hi @lwasylow ,
This is related to data setup.
For my test scenario , I need to insert rows in 20 tables. My approach is

  1. Create external tables for each of the table for the first time and store the data in it and use it each time the test runs . This is kind of one time setup for that test case.
    for example for the original table employee , I will create an external table as tst_employee using "orgnization external" .
 Create table tst_employee
    organization external
    ( type oracle_datapump
    default directory TEST_LOG
    location ('tst_employee.dmp' )
    ) as select *  from employee where customer_ref= 'tst_bv_spend_cap'.
  1. Store this tst_employee.dmp file in a directory called 'test_case_name' in unix.
    3.Likewise if there are 10 test cases I would like to create 10 tst_employee.dmp files with relevant to each of the test cases and keep in each of those directories.
  2. With this my data creation part is done. Now I will clear all the data from original tables . i.e delete from employee.
  3. When I ran my test case , as part of --%beforetest , I am calling my data_setup procedure , in which I am planning to use'insert into employee select * from tst_employee'to populate the data in employee so that my original code to be test would use.
  4. Now I have 10 unix directories in which 10 different data setup files are present which will be used by 10 different test cases.
    7.For each test case I will copy the relevant file .dmp file to a directory called working directory and will remove once the test is completed .
  5. As my test_case_name and unix directory name are same here I am planning to use the test_case_name in a script to copy the file from test case unix directory to working directory. In this way I don't have to create multiple all_directory entries .
  6. As my data_setup procedure doesn't know which test currently being executed (or does it know?) it is difficult to achieve the above copying files to working directory. So , if there is any internal variable that stores the test_case_name which is available in data_setup procedure , it would be handy.

Hope my explanation is clear . Please suggest.

@lwasylow
Copy link
Member

lwasylow commented Nov 9, 2018

I don't think we support functions with parameters as part of before or after at the moment.
What I would suggest as workaround is to create a one procedure that accepts filename and create it.
And then for each test create a wrapper procedure without parameter but with hardcoded file name.

As for your request this is something that have to be looked and investigated a bit further in terms of impact and feasibility.

@MS-24
Copy link
Author

MS-24 commented Nov 10, 2018

Ok ,Thank you

@jgebal
Copy link
Member

jgebal commented Nov 28, 2018

I see two options, probably both would be useful.

  • We could improve the way we use dbms_application_info
  • We could create a dedicated utPLSQL session context that would be able to hold important information durong test execution.

The more i think about it the more i like it. 😀

@lwasylow
Copy link
Member

Application info is restricted to 30 char, not sure if that would be enough.

@Shoelace
Copy link
Member

Shoelace commented Dec 3, 2018

i think a session context is a good idea.. application_inof/module/action can be overwritten by the procedure under test anyway

jgebal added a commit that referenced this issue Jul 2, 2019
> TODO - documentation updates

Added ability to run expectations without tests.
Expectation, when executed without test is reporter straight to dbms_output.
So it is now possible to execute:

`exec ut.expect(1).to_equal(0);`

And get result:

```
FAILURE
  Actual: 1 (number) was expected to equal: 0 (number)
```

Resolves #956

Additionally:
- utPLSQL is now cleaning up the application_info after run.
- utPLSQL is setting session context during run, making it possible to access some of utPLSQL info within the test procedures directly.

Resolves #781

The information is provided in sys_context(`UT3_INFO`,...).

Following attributes are getting populated:
- Always:
    - RUN_PATHS
    - SUITE_DESCRIPTION
    - SUITE_PACKAGE
    - SUITE_PATH
    - SUITE_START_TIME
    - CURRENT_EXECUTABLE_NAME
    - CURRENT_EXECUTABLE_TYPE

- When running in suite context
    - CONTEXT_NAME
    - CONTEXT_PATH
    - CONTEXT_START_TIME
- After first executable in suite
    - TIME_IN_SUITE
- After first executable in suite context
    - TIME_IN_CONTEXT
- When running a test or before/after each/test
    - TEST_DESCRIPTION
    - TEST_NAME
    - TEST_START_TIME
- After first executable in test
    - TIME_IN_TEST
jgebal added a commit that referenced this issue Jul 3, 2019
> TODO - documentation updates

Added ability to run expectations without tests.
Expectation, when executed without test is reporter straight to dbms_output.
So it is now possible to execute:

`exec ut.expect(1).to_equal(0);`

And get result:

```
FAILURE
  Actual: 1 (number) was expected to equal: 0 (number)
```

Resolves #956

Additionally:
- utPLSQL is now cleaning up the application_info after run.
- utPLSQL is setting session context during run, making it possible to access some of utPLSQL info within the test procedures directly.

Resolves #781

The information is provided in sys_context(`UT3_INFO`,...).

Following attributes are getting populated:
- Always:
    - RUN_PATHS
    - SUITE_DESCRIPTION
    - SUITE_PACKAGE
    - SUITE_PATH
    - SUITE_START_TIME
    - CURRENT_EXECUTABLE_NAME
    - CURRENT_EXECUTABLE_TYPE

- When running in suite context
    - CONTEXT_NAME
    - CONTEXT_PATH
    - CONTEXT_START_TIME
- After first executable in suite
    - TIME_IN_SUITE
- After first executable in suite context
    - TIME_IN_CONTEXT
- When running a test or before/after each/test
    - TEST_DESCRIPTION
    - TEST_NAME
    - TEST_START_TIME
- After first executable in test
    - TIME_IN_TEST
@jgebal jgebal removed the discussion label Jul 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants