You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/Core-Features.md
+11-11Lines changed: 11 additions & 11 deletions
Original file line number
Diff line number
Diff line change
@@ -4,16 +4,16 @@
4
4
5
5
---
6
6
## PLSQL Driven Testing
7
-
User written Test Runner packages are collections of assertions. The simplest way to get started with testing is to create a Test Runner package with a single assertion. After the one assertion is successfully running, more assertions and supporting PL/SQL can be added until white-box testing is complete. A Test Runner Package can also call other packages. Groups of assertions can be separated into Test Cases. The Test Runner package can also be the same package as the package being tested (embedded Test Runner).
7
+
User written test runner packages are collections of assertions. The simplest way to get started with testing is to create a test runner package with a single assertion. After the one assertion is successfully running, more assertions and supporting PL/SQL can be added until white-box testing is complete. A test runner package can also call other packages. Groups of assertions can be separated into test cases. The test runner package can also be the same package as the package being tested (embedded test runner).
8
8
9
9
## Test Anything in the Oracle database
10
-
Because the Test Runner packages are user written, they can be used to test anything in the database.
10
+
Because the test runner packages are user written, they can be used to test anything in the database.
11
11
- PL/SQL Packages, Procedures, Functions
12
12
- Table Constraints and Triggers
13
13
- Types and Type Bodies
14
14
15
15
## Built-in Code Coverage
16
-
The Database Object Under Test, or DBOUT, is a database object that is the target of the Test Runner. An annotation is used to identify the DBOUT in a Test Runner Package. If the DBOUT annotation is missing from a Test Runner Package, no code coverage data is collected. If more than one annotation occurs in a Test Runner Package, the first occurrence in the source code is used.
16
+
The Database Object Under Test, or DBOUT, is a database object that is the target of the test runner package. An annotation is used to identify the DBOUT in a test runner package. If the DBOUT annotation is missing from a test runner package, no code coverage data is collected. If more than one annotation occurs in a test runner package, the first occurrence in the source code is used.
17
17
18
18
**Regular Expression:**
19
19
```
@@ -36,30 +36,30 @@ The Database Object Under Test, or DBOUT, is a database object that is the targe
36
36
Occasionally, DBMS_PROFILER does not capture the execution of some PL/SQL source. Examples PL/SQL source that are reported incorrectly include "end if", "select", and "return". wtPLSQL excludes some of these source lines when calculating code coverage metrics. Use the "Ignore" annotations to ignore other lines of PL/SQL when calculating code coverage metrics.
37
37
38
38
## Built-in Schema-wide Testing
39
-
wtPLSQL will locate and execute all Test Runner packages in a schema. This is done by finding all packages with a WTPLSQL_RUN procedure that has no parameters. There is no requirement to pre-define the Test Runners in a schema.
39
+
wtPLSQL will locate and execute all test runner packages in a schema. This is done by finding all packages with a WTPLSQL_RUN procedure that has no parameters. There is no requirement to pre-define the test runners in a schema.
40
40
41
41
## Test Result Capture
42
-
Test results from assertions executed in a Test Runner package are automatically captured in WTPLSQL database tables. Results are stored by Test Runner execution. If specified in the Test Runner, test results are stored by Test Case. If a DBOUT is specified in the Test Runner, code coverage data is also stored. All captured data is automatically deleted except for the last 20 runs of any Test Runner.
42
+
Test results from assertions executed in a test runner package are automatically captured in WTPLSQL database tables. Results are stored by test runner execution. If specified in the test runner, test results are stored by test case. If a DBOUT is specified in the test runner, code coverage data is also stored. All captured data is automatically deleted except for the last 20 runs of any test runner.
43
43
44
44
## Test Result Reporting
45
-
Reporting of the assertion test results is not a included with the execution of the Test Runner(s). A separate call to a Reporting Package must be executed to display the assertion test results. This allows the following choices during test execution:
45
+
Reporting of the assertion test results is not a included with the execution of the test runner package(s). Some other mechanism, like the reporting package, must be used to display the assertion test results. This allows the following choices during test execution:
46
46
-**Run the WT_TEXT_REPORT.DBMS_OUT Report** - This is the default Reporting Package to report test results using DBMS_OUTPUT. Several parameter options are available to change level of detail and report sequencing.
47
47
-**Run an Add-On Reporting Package** - Bespoke reporting packages can be created or downloaded to provide for the exact requirements of test result reporting.
48
48
-**Copy Test Results** - Create or download bespoke storage and reporting systems that copy the test result data from the WTPLSQL database tables for more complex test result reporting.
49
49
-**No Action** - Test results remain in the WTPLSQL database tables until they are automatically deleted.
50
50
51
51
## Stand Alone Assertion Execution
52
-
In utPLSQL V2, executing an assertion outside of the test execution procedure produced an error message. wtPLSQL allows a single assertion can be executed outside of the WTPLSQL.test_run procedure. The results of the assertion will be output to DBMS_OUTPUT. The result is the same when executing a WTPLSQL_RUN procedure in a Test Runner package.
52
+
In utPLSQL V2, executing an assertion outside of the test execution procedure produced an error message. wtPLSQL allows a single assertion can be executed outside of the WTPLSQL.test_run procedure. The results of the assertion will be output to DBMS_OUTPUT. The result is the same when executing a WTPLSQL_RUN procedure in a test runner package.
53
53
54
54
## Private Procedure Testing within a Package
55
-
One of the difficult parts of testing a package is testing the private "internals" within the package. With wtPLSQL, the Test Runner procedure (WTPLSQL_RUN) can be included, or embedded, in the package that is being testing. In this way, the Test Runner has full access to all internal procedures and variables. It also keeps the package and the test together. The Test Runner can be "hidden" in the production deployment by using the "PLSQL_CCFLAGS" conditional compilation select directives. If the directive is missing, FALSE is assumed:
55
+
One of the difficult parts of testing a package is testing the private "internals" within the package. With wtPLSQL, the test runner procedure (WTPLSQL_RUN) can be included, or embedded, in the package that is being testing. In this way, the test runner has full access to all internal procedures and variables. It also keeps the package and the test together. The test runner can be "hidden" in the production deployment by using the "PLSQL_CCFLAGS" conditional compilation select directives. If the directive is missing, FALSE is assumed:
56
56
57
57
```
58
58
alter system set PLSQL_CCFLAGS = 'WTPLSQL_ENABLE:TRUE';
59
59
```
60
60
61
61
## Optional Setup and Teardown
62
-
In utPLSQL V2, setup and teardown procedures were required in each test suite. V2 also has a "per method setup" parameter to control startup and teardown timing/sequencing. In wtPSQL, setup and teardown are optional. Setup and teardown are written into a Test Runner package.
62
+
In utPLSQL V2, setup and teardown procedures were required in each test suite. V2 also has a "per method setup" parameter to control startup and teardown timing/sequencing. In wtPSQL, setup and teardown are optional. Setup and teardown are written into a test runner package.
63
63
64
64
## Simpler Installation Scripts
65
65
In utPLSQL V2, a very sophisticated set of installation scripts are available. The source code for these scripts is very complex. wtPLSQL will use simpler installation scripts for core and option installation. This will require multiple installation steps on the part of the DBA. (Simplicity of coding has priority over convenience of installation)
@@ -68,9 +68,9 @@ In utPLSQL V2, a very sophisticated set of installation scripts are available.
68
68
In utPLSQL V2, an extensive amount of source code is dedicated to the detection and adaptation of previous releases of Oracle, as far back as Oracle database version 6. In wtPLSQL, the minimum edition of the oldest available Oracle database version is supported. Currently, Oracle XE 11gR2 is the minimum edition of the oldest available Oracle database version. Any testing of features in Oracle database releases beyond Oracle 11g XE will be included in Oracle edition and database version specific "options".
69
69
70
70
## Operation Overview
71
-
When the WTPLSQL.test_run procedure is called, a Test Runner package name is passed in as a parameter. The "WTPLSQL_RUN" procedure in the Test Runner package is called with an EXECUTE IMMEDIATE. An exception handler is used in the WTPLSQL package to catch any exceptions raised from a Test Runner Package. Results from assertions are immediately stored in a Nested Table in the WTPLSQL package. After the Test Runner completes execution, the results are transferred into database tables.
71
+
When the WTPLSQL.test_run procedure is called, a test runner package name is passed in as a parameter. The "WTPLSQL_RUN" procedure in the test runner package is called with an EXECUTE IMMEDIATE. An exception handler is used in the WTPLSQL package to catch any exceptions raised from a test runner Package. Results from assertions are immediately stored in a Nested Table in the WTPLSQL package. After the test runner completes execution, the results are transferred into database tables.
72
72
73
-
The WTPLSQL.test_all procedure will locate all Test Runner packages (containing the WTPLSQL_RUN procedure) and execute them using the WTPLSQL.test_run procedure.
73
+
The WTPLSQL.test_all procedure will locate all test runner packages (containing the WTPLSQL_RUN procedure) and execute them using the WTPLSQL.test_run procedure.
Copy file name to clipboardExpand all lines: docs/README.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -44,7 +44,7 @@ Like utPLSQL, wtPLSQL provides a set of assertion tests that can be used to dete
44
44
45
45
A simple text based reporting package called "WT_TEXT_REPORT" is included with the core installation. Custom reports are easy to create because the assertion outcomes and interval time between assertions are stored in the Oracle database. A set of DBDocs and E-R diagrams are provided to assist with any reporting customization.
46
46
47
-
Because all testing with wtPLSQL is for driven by custom PL/SQL packages, a [Best Practices page](Best-Practices.md) has some guidance for creating Test Runner packages.
47
+
Because all testing with wtPLSQL is for driven by custom PL/SQL packages, a [Best Practices page](Best-Practices.md) has some guidance for creating test runner packages.
48
48
49
49
The [About wtPLSQL page](About-wtPLSQL.md) has more information about the history and testing methodology of wtPLSQL.
Copy file name to clipboardExpand all lines: docs/demo/README.md
+66-3Lines changed: 66 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -8,12 +8,75 @@ Demonstrations and examples assume successful connection to an [Oracle database]
8
8
9
9
Test results from assertions can be queried from a set of wtPLSQL tables. The examples here will use the default reporting package called WT_TEXT_REPORT. This package displays test results using DBMS_OUTPUT.
10
10
11
-
12
11
## The Basics
13
12
14
-
The [Simple Stuff](Simple-Stuff.md) page is a confidence builder, excellent for first time users of wtPLSQL.
13
+
A login, or database session, is required to interact with the Oracle database. The SQL below will create a user that can run these examples. If you already have a database login, this is not necessary.
14
+
15
+
```
16
+
create user wtp_demo identified by wtp_demo
17
+
default tablespace users
18
+
quota unlimited on users
19
+
temporary tablespace temp;
20
+
21
+
grant create session to wtp_demo;
22
+
grant create type to wtp_demo;
23
+
grant create sequence to wtp_demo;
24
+
grant create table to wtp_demo;
25
+
grant create trigger to wtp_demo;
26
+
grant create view to wtp_demo;
27
+
grant create procedure to wtp_demo;
28
+
```
29
+
30
+
The simplest check for a wtPLSQL installation is to select the "version from dual".
Another simple test is an ad-hoc assertion. This test requires DBMS_OUTPUT. The results of this test are not recorded.
49
+
50
+
Run this:
51
+
52
+
```
53
+
set serveroutput on size unlimited format word_wrapped
54
+
55
+
begin
56
+
wt_assert.eq(msg_in => 'Ad-Hoc Test'
57
+
,check_this_in => 1
58
+
,against_this_in => '1');
59
+
end;
60
+
/
61
+
```
62
+
63
+
And get this:
64
+
65
+
```
66
+
PASS Ad-Hoc Test. EQ - Expected "1" and got "1"
67
+
```
68
+
69
+
This indicates:
70
+
* the assertion passed
71
+
* the assertion had the message "Ad-Hoc Test"
72
+
* the assertion name is "EQ"
73
+
* the assertion details which may include the values tested
74
+
75
+
Note: This ad-hoc test also demonstrates implicit data type conversion.
76
+
77
+
## Create a Test Runner Package
15
78
16
-
The [Test Runner](Test-Runner.md) page covers all the basics of creating a Test Runner package.
79
+
A test runner package is central to running tests in wtPLSQL. The [Test Runner](Test-Runner.md) page covers all the basics of creating a test runner package.
17
80
18
81
## Database Object Tests
19
82
More interesting examples actually test database objects. Here is an example test of each database object supported by wtPLSQL.
0 commit comments