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/userguide/annotations.md
+13-13Lines changed: 13 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -108,19 +108,19 @@ end test_pkg;
108
108
109
109
| Annotation |Level| Description |
110
110
| --- | --- | --- |
111
-
|`%suite(<description>)`| Package | Mandatory. Marks package as a test suite. Optional suite description can be provided (see `displayname`). |
112
-
|`%suitepath(<path>)`| Package | Similar to java package. The annotation allows logical grouping of suites into hierarchies. |
113
-
|`%displayname(<description>)`| Package/procedure | Human-readable and meaningful description of a suite/test. `%displayname(Name of the suite/test)`. The annotation is provided for flexibility and convenience only. It has exactly the same meaning as `<description>` in `test` and `suite` annotations. If description is provided using both `suite`/`test` and `displayname`, then the one defined as last takes precedence. |
114
-
|`%test(<description>)`| Procedure | Denotes that the annotated procedure is a unit test procedure. Optional test description can by provided (see `displayname`). |
115
-
|`%throws(<exception_number>[,<exception_number>[,...]])`| Procedure | Denotes that the annotated procedure must throw one of the exception numbers provided. If no valid numbers were provided as annotation parameters the annotation is ignored. Applicable to test procedures only. |
116
-
|`%beforeall`| Procedure | Denotes that the annotated procedure should be executed once before all elements of the suite. |
117
-
|`%afterall`| Procedure | Denotes that the annotated procedure should be executed once after all elements of the suite. |
118
-
|`%beforeeach`| Procedure | Denotes that the annotated procedure should be executed before each `%test` procedure in the suite. |
119
-
|`%aftereach`| Procedure | Denotes that the annotated procedure should be executed after each `%test` procedure in the suite. |
120
-
|`%beforetest(<procedure_name>)`| Procedure | Denotes that mentioned procedure should be executed before the annotated `%test` procedure. |
121
-
|`%aftertest(<procedure_name>)`| Procedure | Denotes that mentioned procedure should be executed after the annotated `%test` procedure. |
122
-
|`%rollback(<type>)`| Package/procedure | Defines transaction control. Supported values: `auto`(default) - a savepoint is created before invocation of each "before block" is and a rollback to specific savepoint is issued after each "after" block; `manual` - rollback is never issued automatically. Property can be overridden for child element (test in suite) |
123
-
|`%disabled`| Package/procedure | Used to disable a suite or a test. Disabled suites/tests do not get executed, they are however marked and reported as disabled in a test run. |
111
+
|`--%suite(<description>)`| Package | Mandatory. Marks package as a test suite. Optional suite description can be provided (see `displayname`). |
112
+
|`--%suitepath(<path>)`| Package | Similar to java package. The annotation allows logical grouping of suites into hierarchies. |
113
+
|`--%displayname(<description>)`| Package/procedure | Human-readable and meaningful description of a suite/test. `%displayname(Name of the suite/test)`. The annotation is provided for flexibility and convenience only. It has exactly the same meaning as `<description>` in `test` and `suite` annotations. If description is provided using both `suite`/`test` and `displayname`, then the one defined as last takes precedence. |
114
+
|`--%test(<description>)`| Procedure | Denotes that the annotated procedure is a unit test procedure. Optional test description can by provided (see `displayname`). |
115
+
|`--%throws(<exception_number>[,<exception_number>[,...]])`| Procedure | Denotes that the annotated procedure must throw one of the exception numbers provided. If no valid numbers were provided as annotation parameters the annotation is ignored. Applicable to test procedures only. |
116
+
|`--%beforeall`| Procedure | Denotes that the annotated procedure should be executed once before all elements of the suite. |
117
+
|`--%afterall`| Procedure | Denotes that the annotated procedure should be executed once after all elements of the suite. |
118
+
|`--%beforeeach`| Procedure | Denotes that the annotated procedure should be executed before each `%test` procedure in the suite. |
119
+
|`--%aftereach`| Procedure | Denotes that the annotated procedure should be executed after each `%test` procedure in the suite. |
120
+
|`--%beforetest(<procedure_name>)`| Procedure | Denotes that mentioned procedure should be executed before the annotated `%test` procedure. |
121
+
|`--%aftertest(<procedure_name>)`| Procedure | Denotes that mentioned procedure should be executed after the annotated `%test` procedure. |
122
+
|`--%rollback(<type>)`| Package/procedure | Defines transaction control. Supported values: `auto`(default) - a savepoint is created before invocation of each "before block" is and a rollback to specific savepoint is issued after each "after" block; `manual` - rollback is never issued automatically. Property can be overridden for child element (test in suite) |
123
+
|`--%disabled`| Package/procedure | Used to disable a suite or a test. Disabled suites/tests do not get executed, they are however marked and reported as disabled in a test run. |
Unary matcher that validates if the provided value is false.
@@ -420,7 +429,7 @@ The `a_nulls_are_equal` parameter controls the behavior of a `null = null` compa
420
429
To change the behavior of `NULL = NULL` comparison pass the `a_nulls_are_equal => false` to the `equal` matcher.
421
430
422
431
423
-
## Comparing objects, cursors, collections of data
432
+
## Comparing cursors, object types, nested tables and varrays
424
433
425
434
utPLSQL is capable of comparing compound data-types including:
426
435
- ref cursors
@@ -434,7 +443,7 @@ utPLSQL is capable of comparing compound data-types including:
434
443
- Comparison of cursor columns containing `DATE` will only compare date part **and ignore time** by default. See [Comparing cursor data containing DATE fields](#comparing-cursor-data-containing-date-fields) to check how to enable date-time comparison in cursors.
435
444
- To compare nested table/varray type you need to convert it to `anydata` by using `anydata.convertCollection()`
436
445
- To compare object type you need to convert it to `anydata` by using `anydata.convertObject()`
437
-
- It is possible to compare PL/SQL records and nested tables/varrays/associative arrays of PL/SQL records. To compare this types of data, use cursor comparison feature of utPLSQL and TABLE operator in SQL query
446
+
- It is possible to compare PL/SQL records, collections, varrays and associative arrays. To compare this types of data, use cursor comparison feature of utPLSQL and TABLE operator in SQL query
438
447
- On Oracle 11g Release 2 - pipelined table functions are needed (see section [Implicit (Shadow) Types in this artcile](https://oracle-base.com/articles/misc/pipelined-table-functions))
439
448
- On Oracle 12c and above - use [TABLE function on nested tables/varrays/associative arrays of PL/SQL records](https://oracle-base.com/articles/12c/using-the-table-operator-with-locally-defined-types-in-plsql-12cr1)
440
449
@@ -568,16 +577,16 @@ When comparing rows utPLSQL:
568
577
- reports whole missing (expected) row from expected when expected has extra rows
569
578
570
579
571
-
### Object and collection data-type comparison examples
580
+
### Object and nested table data-type comparison examples
572
581
573
-
When comparing object type to object type or collection to collection, utPLSQL will check:
582
+
When comparing object type / nested table / varray, utPLSQL will check:
574
583
- if data-types match
575
-
- if data in the compared objects/collections are the same.
584
+
- if data in the compared elements is the same.
576
585
577
-
The diff functionality for objects and collections is similar to diff on cursors.
578
-
When diffing objects/collections however, utPLSQL will not check attribute names and data-types.
586
+
The diff functionality for objects / nested tables / varrays is similar to diff on cursors.
587
+
When diffing, utPLSQL will not check name and data-type of individual attribute as the type itself defines the underlying structure.
579
588
580
-
Below examples demonstrate how to compare object and collection data-types.
589
+
Below examples demonstrate how to compare object and nested table data-types.
581
590
582
591
Object type comparison.
583
592
```sql
@@ -589,7 +598,7 @@ begin
589
598
end;
590
599
/
591
600
create or replace package demo_dept as
592
-
--%suite(demo)
601
+
--%suite(demo)
593
602
594
603
--%test(demo of object to object comparison)
595
604
procedure test_department;
@@ -626,7 +635,7 @@ begin
626
635
end;
627
636
/
628
637
create or replace package demo_depts as
629
-
--%suite(demo)
638
+
--%suite(demo)
630
639
631
640
--%test(demo of collection comparison)
632
641
procedure test_departments;
@@ -773,19 +782,21 @@ The matrix below illustrates the data types supported by different matchers.
0 commit comments