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/Other-Definitions.md
+1-23Lines changed: 1 addition & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,30 +1,8 @@
1
1
[Website Home Page](README.md)
2
2
3
-
# Definitions
3
+
# Other Definitions
4
4
5
5
---
6
-
## wtPLSQL
7
-
These are the working definitions for the wtPLSQL project.
8
-
9
-
**Annotation** - PL/SQL comment used to identify a DBOUT or exclude source code lines from code coverage data.
10
-
11
-
**Assertion** - A function that performs a single test and records/reports the result.
12
-
13
-
**Coverage** - An indication of the amount or percentage of source code tested.
14
-
15
-
**DBOUT** - Database Object Under Test. The database object that is the target of testing. White-box testing is oriented toward a specific DBOUT. Code coverage is also oriented toward a specific DBOUT.
16
-
17
-
**SUT** - System Under Test. This includes one or more DBOUTs that comprise an application or system. Continuous Integration (CI) testing is typically done at a system level.
18
-
19
-
**Setup** - Modifying the database or environment in preparation for a test, testcase, or test runner.
20
-
21
-
**Teardown** - Cleaning or restoring a database after a test, testcase, or test runner.
22
-
23
-
**Testcase** - A logical grouping of assertions to run happy path, decision tree, boundary condition, and/or fault insertion tests. May included one or more setup, teardown, and intermediate setups.
24
-
25
-
**Test Runner** - A PL/SQL package that exercises a DBOUT and uses assertions to confirm the correct funcionality of the DBOUT. It may have zero or more testcases. It always contains a call to the WTPLSQL.TEST_RUN procedure. It may contain DBOUT annotations and/or "exclude source lines" annotations.
26
-
27
-
***
28
6
## Oracle Database
29
7
Note: Some Oracle database terms overlap with Object Oriented terms.
Copy file name to clipboardExpand all lines: docs/README.md
+39-20Lines changed: 39 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,26 +9,25 @@ Use [GitHub "issues"](https://github.com/DDieterich/wtPLSQL/issues) for support.
9
9
10
10
## Example wtPLSQL Test Results
11
11
12
-
This is the summary from the WT_ASSERT package self-test. This is the default
13
-
DBMS_OUTPUT format.
12
+
This is the summary from the WT_ASSERT package self-test. This is the default DBMS_OUTPUT format. Because test results and code coverage is stored in Oracle tables, other report formats a simple to create.
14
13
15
14
```
16
-
wtPLSQL 1.1.0 - Run ID 421: 20-May-2018 03:39:54 PM
15
+
wtPLSQL 1.1.0 - Run ID 7: 09-Jun-2018 11:48:42 AM
17
16
18
17
Test Results for WTP.WT_ASSERT
19
-
Total Testcases: 150 Total Assertions: 404
20
-
Minimum Elapsed msec: 0 Failed Assertions: 0
21
-
Average Elapsed msec: 7 Error Assertions: 0
22
-
Maximum Elapsed msec: 1134 Test Yield: 100.00%
23
-
Total Run Time (sec): 2.9
18
+
Total Testcases: 150 Total Assertions: 404
19
+
Minimum Interval msec: 0 Failed Assertions: 0
20
+
Average Interval msec: 7 Error Assertions: 0
21
+
Maximum Interval msec: 761 Test Yield: 100.00%
22
+
Total Run Time (sec): 2.8
24
23
25
24
Code Coverage for PACKAGE BODY WTP.WT_ASSERT
26
-
Ignored Lines: 1103 Total Profiled Lines: 1464
27
-
Excluded Lines: 6 Total Executed Lines: 309
28
-
Minimum Elapsed usec: 0 Not Executed Lines: 0
29
-
Average Elapsed usec: 3054 Unknown Lines: 46
30
-
Maximum Elapsed usec: 332876 Code Coverage: 100.00%
31
-
Trigger Source Offset: 0
25
+
Ignored Lines: 1103 Total Profiled Lines: 1464
26
+
Excluded Lines: 6 Total Executed Lines: 309
27
+
Minimum LineExec usec: 0 Not Executed Lines: 0
28
+
Average LineExec usec: 394 Unknown Lines: 46
29
+
Maximum LineExec usec: 65814 Code Coverage: 100.00%
30
+
Trigger Source Offset: 0
32
31
```
33
32
34
33
To view the complete test results from the wtPLSQL self-test, go to the [test_allO.LST](https://github.com/DDieterich/wtPLSQL/blob/master/src/core/test_allO.LST) file in GitHub.
@@ -38,15 +37,35 @@ To view the complete test results from the wtPLSQL self-test, go to the [test_al
38
37
39
38
wtPLSQL helps with white-box testing of Oracle database objects. It is particularly well suited for unit testing and simple integration testing. It is written in PL/SQL. It contains a self-test which makes it easier to support and customize.
40
39
41
-
Like utPLSQL, wtPLSQL provides a set of assertion tests that can be used to determine how well an Oracle database object is performing. These assertions record the outcome (success or failure) of each test. These assertions also record the time between calls. A test runner (PL/SQL package) must be created with these assertion tests included. When the test runner is executed, the outcome and timing of the assertion tests are recorded. The [Core Features page](Core-Features.md) introduces the main functionality of wtPLSQL.
40
+
Like utPLSQL, wtPLSQL provides a set of assertion tests that can be used to determine how well an Oracle database object is performing. These assertions record the outcome (success or failure) of each test. These assertions also record the time between calls. A test runner (PL/SQL package) must be created with these assertion tests included. The [Core Features page](Core-Features.md) introduces the main functionality of wtPLSQL.
42
41
43
-
A simple text based reporting package called "WT_TEXT_REPORT" is included with the core installation. Custom reports are easy to create because the outcome and timing data is stored in the Oracle database. A set of DBDocs and E-R diagrams are provided to assist with any reporting customization.
42
+
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.
44
43
45
-
Because wtPLSQL is for PL/SQL developers, a [Best Practices page](Best-Practices.md) has some guidance for creating Test Runner packages in PL/SQL.
44
+
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.
46
45
47
-
The [About page](About.md) has more information about the history and testing methodology of wtPLSQL.
46
+
The [About wtPLQSL page](About-wtPLSQL.md) has more information about the history and testing methodology of wtPLSQL.
48
47
49
-
The [Definitions page](Definitions.md) includes definitions from many sources to help define the terms used in various software testing methodologies.
48
+
## wtPLSQL Definitions
49
+
50
+
These are the working definitions for the wtPLSQL project.
51
+
52
+
**Annotation** - PL/SQL comment used to identify a DBOUT or ignore source code lines from code coverage data.
53
+
54
+
**Assertion** - A function that performs a single test and records/reports the result.
55
+
56
+
**Coverage** - An indication of the amount or percentage of source code tested.
57
+
58
+
**DBOUT** - Database Object Under Test. The database object that is the target of testing. White-box testing is oriented toward a specific DBOUT. Code coverage is also oriented toward a specific DBOUT.
59
+
60
+
**Setup** - Modifying the database or environment in preparation for an assertion, testcase, or group of either.
61
+
62
+
**Teardown** - Restoring a database or environment after an assertion, testcase, or group of either.
63
+
64
+
**Testcase** - A logical grouping of assertions to run happy path, decision tree, boundary condition, and/or fault insertion tests. May included one or more setup, teardown, and intermediate setups.
65
+
66
+
**Test Runner** - A PL/SQL package that exercises a DBOUT and uses assertions to confirm the correct funcionality of the DBOUT. It may have zero or more testcases. It always contains a call to the WTPLSQL.TEST_RUN procedure. It may contain DBOUT annotations and/or "exclude source lines" annotations.
67
+
68
+
The [Other Definitions page](Other-Definitions.md) includes definitions from many sources to help define the terms used in various software testing methodologies.
50
69
51
70
## How does wtPLSQL compare to utPLSQL V3?
52
71
@@ -61,7 +80,7 @@ wtPLSQL has a different focus than utPLSQL V3. More information is available [i
Copy file name to clipboardExpand all lines: docs/utPLSQL-V3-Comparison.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,15 +17,15 @@ Abbreviations:
17
17
## Goals
18
18
The "ut3" project ["follows industry standards and best patterns of modern Unit Testing frameworks like JUnit and RSpec"](https://github.com/utPLSQL/utPLSQL).
19
19
20
-
The "wt" project avoids "unit testing" by adopting practices for ["white box testing"](https://github.com/DDieterich/wtPLSQL/wiki/About#white-box-testing).
20
+
The "wt" project avoids "unit testing" by adopting practices for ["white box testing"](https://github.com/DDieterich/wtPLSQL/wiki/About-wtPLSQL#white-box-testing).
21
21
22
22
## Customization
23
23
The "ut3" project incorporates a wide variety of technologies and platforms. It also has a large and diverse set of capabilities that will reduce the need for customization.
24
24
25
25
The "wt" project is centered on one platform with a very simple implementation. It is easier to customize smaller, simpler systems.
26
26
27
27
## Testing Methodologies
28
-
There is a longer discussion about unit testing methodologies in the [About Page](https://github.com/DDieterich/wtPLSQL/wiki/About#unit-testing).
28
+
There is a longer discussion about unit testing methodologies in the [About wtPSQL Page](https://github.com/DDieterich/wtPLSQL/wiki/About-wtPLSQL#unit-testing).
29
29
30
30
Fundamentally, the Oracle database is a relational database. The relational database is based on transaction processing. Data is stored and shared in a precise manner between processes.
31
31
@@ -58,7 +58,7 @@ TDD places no value on 100% code coverage. TDD typically avoids testing sad path
58
58
59
59
White box testing is centered on 100% code coverage. "Happy path" and "sad path" testing are typically required to achieve 100% code coverage.
60
60
61
-
Here is more discussion on [Test Driven Development](About.html#test-driven-development)
61
+
Here is more discussion on [Test Driven Development](About-wtPLSQL.html#test-driven-development)
comment on table PLSQL_PROFILER_RUNS is 'Table of profiler runs for DBMS_PROFILER';
10
+
comment on column PLSQL_PROFILER_RUNS.runid is '(PRIMARY KEY) Unique run identifier from plsql_profiler_runnumber';
11
+
comment on column PLSQL_PROFILER_RUNS.related_run is 'Runid of related run (for client/server correlation)';
12
+
comment on column PLSQL_PROFILER_RUNS.run_owner is 'User who started run';
13
+
comment on column PLSQL_PROFILER_RUNS.run_date is 'Start time of run';
14
+
comment on column PLSQL_PROFILER_RUNS.run_comment is 'User provided comment for this run';
15
+
comment on column PLSQL_PROFILER_RUNS.run_total_time is 'Elapsed time for this run in nanoseconds';
16
+
comment on column PLSQL_PROFILER_RUNS.run_system_info is 'Currently unused';
17
+
comment on column PLSQL_PROFILER_RUNS.run_comment1 is 'Additional comment';
18
+
comment on column PLSQL_PROFILER_RUNS.spare1 is 'Unused';
19
+
20
+
comment on table PLSQL_PROFILER_UNITS is 'Table of program units for DBMS_PROFILER';
21
+
comment on column PLSQL_PROFILER_UNITS.runid is '(Primary key) References plsql_profiler_runs';
22
+
comment on column PLSQL_PROFILER_UNITS.unit_number is '(Primary key) Internally generated library unit #';
23
+
comment on column PLSQL_PROFILER_UNITS.unit_type is 'Library unit type';
24
+
comment on column PLSQL_PROFILER_UNITS.unit_owner is 'Library unit owner name';
25
+
comment on column PLSQL_PROFILER_UNITS.unit_name is 'Library unit name timestamp on library unit';
26
+
comment on column PLSQL_PROFILER_UNITS.unit_timestamp is 'In the future will be used to detect changes to unit between runs';
27
+
comment on column PLSQL_PROFILER_UNITS.total_time is 'Total time spent in this unit in nanoseconds. The profiler does not set this field, but it is provided for the convenience of analysis tools';
28
+
comment on column PLSQL_PROFILER_UNITS.spare1 is 'Unused';
29
+
comment on column PLSQL_PROFILER_UNITS.spare2 is 'Unused';
30
+
31
+
comment on table PLSQL_PROFILER_DATA is 'Table of program units for DBMS_PROFILER';
32
+
comment on column PLSQL_PROFILER_DATA.runid is 'Primary key, unique (generated) run identifier';
33
+
comment on column PLSQL_PROFILER_DATA.unit_number is 'Primary key, internally generated library unit number';
34
+
comment on column PLSQL_PROFILER_DATA.line# is 'Primary key, not null, line number in unit';
35
+
comment on column PLSQL_PROFILER_DATA.total_occur is 'Number of times line was executed';
36
+
comment on column PLSQL_PROFILER_DATA.total_time is 'Total time spent executing line in nanoseconds';
37
+
comment on column PLSQL_PROFILER_DATA.min_time is 'Minimum execution time for this line in nanoseconds';
38
+
comment on column PLSQL_PROFILER_DATA.max_time is 'Maximum execution time for this line in nanoseconds';
39
+
comment on column PLSQL_PROFILER_DATA.spare1 is 'Unused';
40
+
comment on column PLSQL_PROFILER_DATA.spare2 is 'Unused';
41
+
comment on column PLSQL_PROFILER_DATA.spare3 is 'Unused';
42
+
comment on column PLSQL_PROFILER_DATA.spare4 is 'Unused';
0 commit comments