Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add ability to get expectation results without test-suite #956

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

Closed
jgebal opened this issue Jun 24, 2019 · 0 comments · Fixed by #963
Closed

Add ability to get expectation results without test-suite #956

jgebal opened this issue Jun 24, 2019 · 0 comments · Fixed by #963

Comments

@jgebal
Copy link
Member

jgebal commented Jun 24, 2019

Describe the solution you'd like
Currently, to see the outcomes of ut.expect... one needs to create unit test package spec, unit test body and invoke the ut.run.
For some very simple (basic) test cases it would be hugely beneficial to allow invocation of expectations as it is possible in groovy.
For example, groovy allows for one-line asserts in groovy console:

def strArray = new String[3]
assert strArray instanceof String[]
strArray[0] = 'mrhaki'
strArray.putAt(1, 'Groovy')  // New syntax.
strArray[2] = 'Java'
 
assert 'mrhaki' == strArray.getAt(0)  // Just another way to get a value.

It would be great to be able to invoke utPSLQL expecations in similar way from SQLPlus or any other SQL console, example:

exec ut.expect(1).to_equal(2);

Additional context
When running outside of utPLSQL test-run, expectations should provide outputs straight to screen.
When running within utPSLQL test-run, they should provide outputs as they do today (to be consumed by reporters)

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
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.

1 participant