|
1 | 1 | # Annotations |
2 | 2 |
|
3 | 3 | Annotations provide a way to configure tests and suites in a declarative way similar to modern OOP languages. |
| 4 | +The annotation list is based on jUnit 5 implementation. |
4 | 5 |
|
5 | 6 | # Example |
6 | 7 | Let's say we have the test package like this: |
7 | 8 | ``` |
8 | 9 | create or replace package test_pkg is |
9 | 10 |
|
10 | | - -- %suite(Name of suite) |
11 | | - -- %suitepackage(all.globaltests) |
12 | | - -- %suitetype(critical) |
| 11 | + -- %suite |
| 12 | + -- %displayname(Name of suite) |
| 13 | + -- %suitepath(all.globaltests) |
13 | 14 |
|
14 | | - -- %suitesetup |
| 15 | + -- %beforeall |
15 | 16 | procedure globalsetup; |
16 | 17 |
|
17 | | - -- %suiteteardown |
| 18 | + -- %afterall |
18 | 19 | procedure global_teardown; |
19 | 20 |
|
20 | 21 | /* Such comments are allowed */ |
21 | 22 |
|
22 | | - -- %test(Name of test1) |
23 | | - -- %testtype(smoke) |
| 23 | + -- %test |
| 24 | + -- %displayname(Name of test1) |
24 | 25 | procedure test1; |
25 | 26 |
|
26 | | - -- %test(Name of test2) |
27 | | - -- %testsetup(setup_test1) |
28 | | - -- %testteardown(teardown_test1) |
| 27 | + -- %test |
| 28 | + -- %displayname(Name of test2) |
| 29 | + -- %beforetest(setup_test1) |
| 30 | + -- %aftertest(teardown_test1) |
29 | 31 | procedure test2; |
30 | 32 |
|
31 | | - -- %test(Name of test3) |
| 33 | + -- %test |
| 34 | + -- %displayname(Name of test3) |
32 | 35 | -- %testtype(smoke) |
33 | 36 | procedure test3; |
34 | 37 |
|
35 | 38 | procedure setup_test1; |
36 | 39 |
|
37 | 40 | procedure teardown_test1; |
38 | 41 |
|
39 | | - -- %setup |
| 42 | + -- %beforeeach |
40 | 43 | procedure setup; |
41 | 44 |
|
42 | | - -- %teardown |
| 45 | + -- %aftereach |
43 | 46 | procedure teardown; |
44 | 47 |
|
45 | 48 | end test_pkg; |
46 | 49 | ``` |
47 | 50 |
|
48 | 51 | #Annotations meaning |
49 | 52 |
|
50 | | -Annotation | Meaning |
51 | | ------------- | ------------- |
52 | | -%suite | Marks package to be a suite with it procedures as tests. This way all testing packages might be found in the schema. Parameter of the annotation is the Suite name |
53 | | -%suitepackage | Similar to java package. The example suite should be put as an element of the "globaltests" suite which is an element of the "all" suite. This allows one to execute "glovaltests" suite which would recursively run all the child suites including this one. |
54 | | -%suitetype | The way for suite to have something like a type. One might collect suites based on the subject of tests (a system module for example). There might be critical tests to run every time and more covering but slow tests. This technique allows to configure something like "fast" testing. |
55 | | -%setup | Marks procedure as a default setup procedure for the suite. |
56 | | -%teardown | Marks procedure as a default teardown procedure for the suite. |
57 | | -%test | Marks procedure as a test. Parameter is a name of the test |
58 | | -%testtype | Another way to tag tests to filter afterwards |
59 | | -%testsetup | Marks that special setup procedure has to be run before the test instead of the default one |
60 | | -%testteardown | Marks that special teardown procedure has to be run before the test instead of the default one |
61 | | -%suitesetup | Procedure with executes once at the beginning of the suite and doesn't executes before each test |
62 | | -%suiteteardown | Procedure with executes once after the execution of the last test in the suite. |
| 53 | +| Annotation |Level| Describtion | |
| 54 | +| --- | --- | --- | |
| 55 | +| `%suite` | Package | Marks package to be a suite of tests This way all testing packages might be found in a schema. | |
| 56 | +| `%suitepath(<path>)` | Package | Similar to java package. The annotation allows logical grouping of suites into hierarcies. | |
| 57 | +| `%displayname(<description>)` | Package/procedure | Human-familiar describtion of the suite/test. `%displayname(Name of the suite/test)` | |
| 58 | +| `%test` | Procedure | Denotes that a method is a test method. | |
| 59 | +| `%beforeall` | Procedure | Denotes that the annotated procedure should be executed before all `%test` methods in the current suite. | |
| 60 | +| `%afterall` | Procedure | Denotes that the annotated procedure should be executed after all `%test` methods in the current suite. | |
| 61 | +| `%beforeeach` | Procedure | Denotes that the annotated procedure should be executed before each `%test` method in the current suite. | |
| 62 | +| `%aftereach` | Procedure | Denotes that the annotated procedure should be executed after each `%test` method in the current suite. | |
| 63 | +| `%beforetest(<procedure_name>)` | Procedure | Denotes that mentioned procedure should be executed before the annotated `%test` procedure. | |
| 64 | +| `%aftertest(<procedure_name>)` | Procedure | Denotes that mentioned procedure should be executed after the annotated `%test` procedure. | |
| 65 | +| `%rollback(<type>)` | Package/procedure | Configure transaction control behaviour (type). Supported values: `auto`(default) - rollback to savepoint (before the test/suite setup) is issued after each test/suite teardown; `manual` - rollback is never issued automatically. Property can be overridden for child element (test in suite) | |
| 66 | +| `%disable` | Package/procedure | Used to disable a suite or a test | |
63 | 67 |
|
64 | 68 | Annotations allow us to configure test infrastructure in a declarative way without anything stored in tables or config files. Suite manager would scan the schema for all the suitable packages, automatically configure suites and execute them. This can be simplified to the situation when you just ran suite manager over a schema for the defined types of tests and reporters and everything goes automatically. This is going to be convenient to be executed from CI tools using standard reporting formats. |
65 | | - |
|
0 commit comments