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/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
- Quick notes to run the Testaro validation tests locally (Windows PowerShell):
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
 
@@ -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
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "testaro",
3
- "version": "68.0.0",
3
+ "version": "69.0.0",
4
4
  "description": "Run 1000 web accessibility tests from 11 tools and get a standardized report",
5
5
  "main": "index.js",
6
6
  "scripts": {
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',