Ability to run expectations without test #963
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
> 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
…e of low value and could bing confusion.
e172d40 to
99bae42
Compare
- Changed how stack trace is reported on expectations to provide more information to the user.
- Fixed expectation messages for successful results
- moved `to_be_empty` / `not_to_be_empty` to base `ut_expectation` type as it's available for `clob`/`blob` types too.
- added-back grant on `ut_matcher` to allow for passing various matchers by users.
- fixed issue with misleading message: `All rows are different as the columns position is not matching` when comparing a null collection/cursor
{WIP] Updates to documentation for expectations.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added ability to run expectations without tests
Expectation, when executed without test, reports results straight to dbms_output.
So it is now possible to execute:
exec ut.expect(1).to_equal(0);And get result:
Resolves #956
Improvements to application_info in v$session
utPLSQL is now cleaning up the application_info after run. The
module_name,action, client_info` are restored to it's original values after test run. Resolves #951The following attributes are set in v$session when test suite is running:
module_name- set toutPLSQLaction- name of currently executing test suite packageclient_infoname of test executable procedure (before.../after.../test) that is currently runningSetting session context during run
It is now possible to access some of utPLSQL info within the test procedures directly.
Resolves #781
The information is provided in
sys_context( 'UT3_INFO', attribute ).Following attributes are getting populated:
Always:
sys_context( 'UT3_INFO', 'RUN_PATHS' );- list of suitepaths / suitenames used as input parameters for call tout.run(...)orut_runner.run(...)sys_context( 'UT3_INFO', 'SUITE_DESCRIPTION' );- the description of test suite that is currently being executedsys_context( 'UT3_INFO', 'SUITE_PACKAGE' );- the owner and name of test suite package that is currently being executedsys_context( 'UT3_INFO', 'SUITE_PATH' );- the suitepath for the test suite package that is currently being executedsys_context( 'UT3_INFO', 'SUITE_START_TIME' );- the execution start timestamp of test suite package that is currently being executedsys_context( 'UT3_INFO', 'CURRENT_EXECUTABLE_NAME' );- the owner.package.procedure of currently running test suite executablesys_context( 'UT3_INFO', 'CURRENT_EXECUTABLE_TYPE' );- the type of currently running test suite executable (one of:beforeall,beforeeach,beforetest,test,aftertest,aftereach,afterallWhen running in suite context
sys_context( 'UT3_INFO', 'CONTEXT_DESCRIPTION' );- the description of test suite context that is currently being executedsys_context( 'UT3_INFO', 'CONTEXT_NAME' );- the name of test suite context that is currently being executedsys_context( 'UT3_INFO', 'CONTEXT_PATH' );- the suitepath for the currently executed test suite contextsys_context( 'UT3_INFO', 'CONTEXT_START_TIME' );- the execution start timestamp for the currently executed test suite contextWhen running a suite executable procedure that is a
testorbeforeeach,aftereach,beforetest,aftertestsys_context( 'UT3_INFO', 'TEST_DESCRIPTION' );- the description of test for which the current executable is being invokedsys_context( 'UT3_INFO', 'TEST_NAME' );- the name of test for which the current executable is being invokedsys_context( 'UT3_INFO', 'TEST_START_TIME' );- the execution start timestamp of test that is currently being executed (the time when firstbeforeeach/beforetestwas called for that test)Call stack enchancements
utPLSQL will now provide full call stack within the context of the test, not only the stack line where expectation was called.
To minimize overhead on test execution, stack is provided only when expectation fails.
Resolves #967
Improved functionality of reporters
Reporters will now support inline calls for data-retrieval.
References #955