|
| 1 | +# Decorator Test Notes |
| 2 | + |
| 3 | +## Terminology |
| 4 | + |
| 5 | +Some terms are simplified in these tests to make it easier to communicate |
| 6 | +meaning and intent. |
| 7 | + |
| 8 | +- **static** is used to refer to all class elements that are used with the |
| 9 | + `static` keyword, including fields and methods. This should be thought of as |
| 10 | + "elements that belong to the class definition". |
| 11 | + |
| 12 | +- **instance** is used to refer to all class elements that are used _without_ |
| 13 | + the static keyword, including fields and methods. This should be thought as |
| 14 | + "elements that belong to the class instance". Some of these elements are |
| 15 | + assigned to the class prototype rather than the instance, but from a typical |
| 16 | + usage perspective, a user will only call these methods when dealing with an |
| 17 | + instance of the class. Most users do not ever deal directly with the class |
| 18 | + prototype. |
| 19 | + |
| 20 | +- **methods** refers to all public/private _methods_, _getters_, and _setters_. |
| 21 | + These are elements that do _not_ have a per-instance initializer, and for this |
| 22 | + reason they are grouped together for things like initialization and decorator |
| 23 | + application. |
| 24 | + |
| 25 | +- **fields** refers to all public/private _fields_ and _accessors_. Accessors |
| 26 | + here refers to auto-accessors created with the `accessor` keyword, _NOT_ |
| 27 | + getters and setters created with the `get` and `set` keywords. These are |
| 28 | + elements that _have_ an initialization step per-instance, and grouped |
| 29 | + together for initialization and decorator application for that reason. |
| 30 | + |
| 31 | +- **Extra-initializers** refers to all initializers added via |
| 32 | + `context.addInitializer`. This distinguishes them from standard initializers |
| 33 | + for fields and accessors, which run in a different order and with different |
| 34 | + timing. |
| 35 | + |
| 36 | +## Structure |
| 37 | + |
| 38 | +- Element decorator templates all follow the same basic structure in order to |
| 39 | + share as much code as possible for repeated tests. |
| 40 | + |
| 41 | + - The class element being tested is named `element` for public elements and |
| 42 | + `#element` for private elements. |
| 43 | + |
| 44 | + - If the element is gettable, there is a `getElement` public method that |
| 45 | + directly gets the element. If the element is a field, accessor, or getter, |
| 46 | + this will call any getters and return the value. If it is a method, it will |
| 47 | + return the method itself. Setters are not gettable. |
| 48 | + |
| 49 | + - These is a `setElement` public method that directly sets the element. If the |
| 50 | + element is a field, accessor, or setter, this will call any setters and set |
| 51 | + the value. Getters and methods are not settable. |
| 52 | + |
| 53 | +- Each element template folder is broken down into the following directory |
| 54 | + structure: |
| 55 | + |
| 56 | + ``` |
| 57 | + . |
| 58 | + └── [element type]/ |
| 59 | + └── [test case type]/ |
| 60 | + ├── private/ |
| 61 | + │ ├── instance/ |
| 62 | + │ │ ├── cls-decl.template |
| 63 | + │ │ └── cls-expr.template |
| 64 | + │ └── static/ |
| 65 | + │ ├── cls-decl.template |
| 66 | + │ └── cls-expr.template |
| 67 | + └── public/ |
| 68 | + ├── instance/ |
| 69 | + │ ├── cls-decl.template |
| 70 | + │ └── cls-expr.template |
| 71 | + └── static/ |
| 72 | + └── cls-decl.template/ |
| 73 | + └── cls-expr.template |
| 74 | + ``` |
| 75 | + |
| 76 | + This structure allows each test to easily select the types of values it |
| 77 | + applies to and test them across both class declarations and expressions. |
| 78 | + Private and public are split out because there are some common differences |
| 79 | + between them (e.g. `context.private`, `context.name`) and the same is true for |
| 80 | + static vs instance (e.g. `context.static`). |
| 81 | + |
| 82 | + |
0 commit comments