testaro 68.0.0 → 69.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +232 -683
- package/UPGRADES.md +4 -0
- package/VALIDATION.md +62 -1
- package/actSpecs-doc.md +53 -0
- package/package.json +1 -1
- package/procs/catalog.js +2 -2
- package/tests/htmlcs.js +1 -1
- package/tests/testaro.js +1 -4
package/UPGRADES.md
CHANGED
|
@@ -3259,3 +3259,7 @@ That will help you see whether future failures cluster around late DOM injection
|
|
|
3259
3259
|
## Status
|
|
3260
3260
|
Your fix is a sensible incremental change; keep it for now, and if you see new mismatches, the next step is adding a DOM-stability heuristic or an overlay-handling step rather than abandoning the approach.
|
|
3261
3261
|
```
|
|
3262
|
+
|
|
3263
|
+
### Automated accessibility testing at Slack
|
|
3264
|
+
|
|
3265
|
+
[Automated accessibility testing at Slack](https://slack.engineering/automated-accessibility-testing-at-slack/) is based on Playwright, with Axe as a single tool.
|
package/VALIDATION.md
CHANGED
|
@@ -1,6 +1,67 @@
|
|
|
1
1
|
# Validation
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
## Introduction
|
|
4
|
+
|
|
5
|
+
Testing the correctness of Testaro is named “validation” rather than “testing”, for confusion avoidance.
|
|
6
|
+
|
|
7
|
+
The original strategy for validation is to permit any test act to contain an `expect` property, whose value specifies a fact about the result. The specification language is a custom Testaro-specific language. When an act in a job has an `expect` property, then the act in the corresponding report contains an `expectations` property that describes the success or failure of the result to conform to the specification.
|
|
8
|
+
|
|
9
|
+
In practice, no use of the `expect`/`expectations` pattern is known except for test acts whose tool is `testaro`. The other tools are treated as black boxes with no contracts entitling Testaro to hold the tools accountable for compliance. Thus, the pattern has been used for the validation of the tests of the `testaro` tool.
|
|
10
|
+
|
|
11
|
+
It may be appropriate to replace the pattern with a conventional testing approach that is widely practiced and understood, based on a platform such as Vitest and/or Playwright. While such a replacement is being considered, the documentation on the pattern that has been part of the `README.md` file is moved into this document. Here it is named “classic validation”.
|
|
12
|
+
|
|
13
|
+
## Classic validation
|
|
14
|
+
|
|
15
|
+
### Expectations
|
|
16
|
+
|
|
17
|
+
Any `test` act can contain an `expect` property. If it does, the value of that property must be an array of arrays. Each array specifies expectations about the results of the operation of the tool.
|
|
18
|
+
|
|
19
|
+
For example, a `test` act might have this `expect` property:
|
|
20
|
+
|
|
21
|
+
```javaScript
|
|
22
|
+
'expect': [
|
|
23
|
+
['standardResult.totals.0', '=', 0],
|
|
24
|
+
['standardResult.instances.length', '=', 0]
|
|
25
|
+
]
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
That would state the expectations that the `standardResult` property of the act will report no rule violations at severity level 0 and no instances of rule violations.
|
|
29
|
+
|
|
30
|
+
The first item in each array is an identifier of a property of the act. The item has the format of a string with `.` delimiters. Each `.`-delimited segment its the name of the next property in the hierarchy. If the current object is an array, the next segment must be a non-negative integer, representing the index of an element of the array.
|
|
31
|
+
|
|
32
|
+
If there is only 1 item in an array, it states the expectation that the specified property does not exist. Otherwise, there are 3 items in the array.
|
|
33
|
+
|
|
34
|
+
The second item in each array, if there are 3 items, is an operator, drawn from:
|
|
35
|
+
|
|
36
|
+
- `<`: less than
|
|
37
|
+
- `=`: equal to
|
|
38
|
+
- `>`: greater than
|
|
39
|
+
- `!`: unequal to
|
|
40
|
+
- `i`: includes
|
|
41
|
+
- `e`: equivalent to (parsed identically as JSON)
|
|
42
|
+
|
|
43
|
+
The third item in each array, if there are 3 items in the array, is the criterion with which the value of the first property is compared.
|
|
44
|
+
|
|
45
|
+
A typical use for an `expect` property is checking the correctness of a Testaro test. Thus, the validation jobs in the `validation/tests/jobs` directory all contain `test` acts with `expect` properties. See the “Validation” section below.
|
|
46
|
+
|
|
47
|
+
### Validators
|
|
48
|
+
|
|
49
|
+
Testaro and the tests of the Testaro tool can be validated with the _executors_ located in the `validation/executors` directory.
|
|
50
|
+
|
|
51
|
+
The executor for a single test is `test`. To execute it for any test `xyz`, call it with the statement `npm test xyz`.
|
|
52
|
+
|
|
53
|
+
The other executors are:
|
|
54
|
+
|
|
55
|
+
- `run`: validates immediate test execution
|
|
56
|
+
- `watchDir`: validates directory watching
|
|
57
|
+
- `watchNet`: validates network watching
|
|
58
|
+
- `tests`: validates all the Testaro tests
|
|
59
|
+
|
|
60
|
+
To execute any executor `xyz` among these, call it with the statement `npm run xyz`.
|
|
61
|
+
|
|
62
|
+
The `tests` executor makes use of the jobs in the `validation/tests/jobs` directory, and they, in turn, run tests on HTML files in the `validation/tests/targets` directory.
|
|
63
|
+
|
|
64
|
+
### Validation in Windows PowerShell
|
|
4
65
|
|
|
5
66
|
1. Install project dependencies
|
|
6
67
|
|
package/actSpecs-doc.md
ADDED
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
# actSpecs
|
|
2
|
+
|
|
3
|
+
## Introduction to the `actSpecs` file
|
|
4
|
+
|
|
5
|
+
The `actSpecs.js` file contains rules governing acts. The rules determine whether an act is valid.
|
|
6
|
+
|
|
7
|
+
## Rule format
|
|
8
|
+
|
|
9
|
+
The rules in `actSpecs.js` are organized into two objects, `etc` and `tools`. The `etc` object contains rules for acts of all types. The `tools` object contains additional rules that apply to some acts of type `test`, depending on the values of their `which` properties, namely which tools they perform tests of.
|
|
10
|
+
|
|
11
|
+
Here is an example of an act:
|
|
12
|
+
|
|
13
|
+
```json
|
|
14
|
+
{
|
|
15
|
+
"type": "link",
|
|
16
|
+
"which": "warming",
|
|
17
|
+
"what": "article on climate change"
|
|
18
|
+
}
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
And here is the applicable property of the `etc` object in `actSpecs.js`:
|
|
22
|
+
|
|
23
|
+
```js
|
|
24
|
+
link: [
|
|
25
|
+
'Click a link',
|
|
26
|
+
{
|
|
27
|
+
which: [true, 'string', 'hasLength', 'substring of the link text'],
|
|
28
|
+
what: [false, 'string', 'hasLength', 'comment']
|
|
29
|
+
}
|
|
30
|
+
]
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
The rule is an array with two elements: a string ('Click a link') describing the act and an object containing requirements for any act of type `link`.
|
|
34
|
+
|
|
35
|
+
The requirement `which: [true, 'string', 'hasLength', 'substring of the link text']` specifies what is required for the `which` property of a `link`-type act. The requirement is an array.
|
|
36
|
+
|
|
37
|
+
In most cases, the array has length 4:
|
|
38
|
+
|
|
39
|
+
- Item 0. Is the property (here `which`) required (`true` or `false`)? The value `true` here means that every `link`-type act **must** contain a `which` property.
|
|
40
|
+
- Item 1. What format must the property value have (`'string'`, `'array'`, `'boolean'`, `'number'`, or `'object'`)?
|
|
41
|
+
- Item 2. What other validity criterion applies (if any)? (Empty string if none.) The `hasLength` criterion means that the string must be at least 1 character long.
|
|
42
|
+
- Item 3. Description of the property. In this example, the description says that the value of `which` must be a substring of the text content of the link that is to be clicked. Thus, a `link` act tells Testaro to find the first link whose text content has this substring and click it.
|
|
43
|
+
|
|
44
|
+
The validity criterion named in item 2 may be any of these:
|
|
45
|
+
|
|
46
|
+
- `'hasLength'`: is not a blank string
|
|
47
|
+
- `'isURL`': is a string starting with `http`, `https`, or `file`, then `://`, then ending with 1 or more non-whitespace characters
|
|
48
|
+
- `'isBrowserType'`: is `'chromium'`, `'firefox'`, or `'webkit'`
|
|
49
|
+
- `'isFocusable'`: is `'a'`, `'button'`, `'input'`, `'select'`, or `'option'`
|
|
50
|
+
- `'isState'`: is `'loaded'` or `'idle'`
|
|
51
|
+
- `'isTest'`: is the name of a tool
|
|
52
|
+
- `'isWaitable'`: is `'url'`, `'title'`, or `'body'`
|
|
53
|
+
- `'areStrings'`: is an array of strings
|
package/package.json
CHANGED
package/procs/catalog.js
CHANGED
|
@@ -74,7 +74,7 @@ exports.getCatalog = async report => {
|
|
|
74
74
|
const tidySegments = segments?.map(segment => segment.trim().replace(/\s+/g, ' ')) ?? [];
|
|
75
75
|
const neededSegments = tidySegments.filter(segment => segment.length);
|
|
76
76
|
neededSegments.splice(1, neededSegments.length - 2);
|
|
77
|
-
const text = addToCatalog(index, cat, 'text', neededSegments.join('
|
|
77
|
+
const text = addToCatalog(index, cat, 'text', neededSegments.join('\n'));
|
|
78
78
|
const domRect = element.getBoundingClientRect();
|
|
79
79
|
const boxID = addToCatalog(
|
|
80
80
|
index,
|
|
@@ -90,8 +90,8 @@ exports.getCatalog = async report => {
|
|
|
90
90
|
tagName,
|
|
91
91
|
id,
|
|
92
92
|
startTag,
|
|
93
|
-
textLinkable: false,
|
|
94
93
|
text,
|
|
94
|
+
textLinkable: false,
|
|
95
95
|
boxID,
|
|
96
96
|
pathID
|
|
97
97
|
};
|
package/tests/htmlcs.js
CHANGED
|
@@ -129,7 +129,7 @@ exports.reporter = async (page, report, actIndex) => {
|
|
|
129
129
|
// If standard results are to be reported:
|
|
130
130
|
if (standard) {
|
|
131
131
|
const instance = {
|
|
132
|
-
ruleID: parts[1]
|
|
132
|
+
ruleID: `${parts[0][0]}-${parts[1]}`,
|
|
133
133
|
what: parts[4],
|
|
134
134
|
ordinalSeverity: parts[0] === 'Warning' ? 0 : 2,
|
|
135
135
|
count: 1
|
package/tests/testaro.js
CHANGED
|
@@ -20,10 +20,7 @@ const {launch} = require('../procs/launch');
|
|
|
20
20
|
|
|
21
21
|
// CONSTANTS
|
|
22
22
|
|
|
23
|
-
|
|
24
|
-
Metadata of all rules in default execution order.
|
|
25
|
-
Property needsLaunch is true if the rule is first or the previous one contaminates the page.
|
|
26
|
-
*/
|
|
23
|
+
// Metadata of all rules in default execution order.
|
|
27
24
|
const allRules = [
|
|
28
25
|
{
|
|
29
26
|
id: 'shoot0',
|