testaro 13.0.2 → 14.0.0

package/README.md

@@ -1,27 +1,32 @@
 # testaro
 
-Federated accessibility test automation
+Ensemble testing for web accessibility
 
 ## Summary
 
 Testaro is a collection of web accessibility testing tools.
 
-The purpose of Testaro is to provide programmatic access to accessibility tests defined by several tools, including Testaro itself.
+The purpose of Testaro is to provide programmatic access to accessibility tests defined by several tools.
 
 Testaro launches and controls web browsers, performing operations, conducting tests, and recording results.
 
-Testaro is designed to be a workstation-based agent. Testaro can be installed on a workstation running under OS X or Windows, or potentially Ubuntu Linux. Software that uses Testaro can be installed on the same workstation or any other workstation or server. Such other software can perform functions that do not require workstation features, such as:
-- Test scheduling
-- Monitoring
+Testaro is designed to be a workstation-based agent, because many of the tests performed by Testaro simulate the use of a web browser on a workstation. Testaro can be installed under MacOS, Windows, or potentially Ubuntu Linux.
+
+Testaro accepts _jobs_, performs them, and returns _reports_.
+
+Other software, located on any server or on the same workstation, can make use of Testaro, performing functions such as:
+- Job preparation
+- Converting user specifications into jobs
+- Job scheduling
+- Monitoring of the health of Testaro
 - Management of clusters of workstations sharing workloads
 - Allocation of responsibilities among workstations
-- Receiving and fulfilling requests from users for testing
-- Converting user specifications into instructions for workstations
+- Receiving and fulfilling requests from users for jobs
 - Allocating testing responsibilities to human testers
 - Combining reports from workstations and human testers
 - Analyzing and summarizing (e.g., computing scores on the basis of) test results
 - Sending notifications
-- Publishing reports
+- Revising, combining, and publishing reports
 
 One software product that performs some such functions is [Testilo](https://www.npmjs.com/package/testilo).
 
@@ -31,9 +36,7 @@ Testaro uses:
 - [Playwright](https://playwright.dev/) to launch browsers, perform user actions in them, and perform tests
 - [pixelmatch](https://www.npmjs.com/package/pixelmatch) to measure motion
 
-Testaro includes some of its own accessibility tests. Some of them are derived from tests performed by the [BBC Accessibility Standards Checker](https://github.com/bbc/bbc-a11y).
-
-In addition, Testaro performs tests of these tools:
+Testaro performs tests of these tools:
 - [accessibility-checker](https://www.npmjs.com/package/accessibility-checker) (IBM)
 - [alfa](https://alfa.siteimprove.com/) (Siteimprove)
 - [axe-playwright](https://www.npmjs.com/package/axe-playwright) (Deque)
@@ -42,8 +45,11 @@ In addition, Testaro performs tests of these tools:
 - [Nu Html Checker](https://github.com/validator/validator) (World Wide Web Consortium)
 - [QualWeb core](https://www.npmjs.com/package/@qualweb/core) (University of Lisbon)
 - [Tenon](https://tenon.io/documentation/what-tenon-tests.php) (Tenon)
+- [Testaro](https://www.npmjs.com/package/testaro) (Testaro)
 - [WAVE API](https://wave.webaim.org/api/) (WebAIM)
 
+The [BBC Accessibility Standards Checker](https://github.com/bbc/bbc-a11y) is not a formal dependency, but some of the tests in the Testaro tool are adaptations of tests of that tool.
+
 As of this version, the counts of tests of the tools referenced above were:
 - Alfa: 103
 - Axe-core: 138
@@ -62,8 +68,8 @@ Of the 29 Testaro tests, 26 are evaluative (they discover accessibility issues),
 ## Quasi-tests
 
 Reports produced by Testaro contain data in addition to the results of these tests. Such data can be used like tests. In particular, the data include:
-- Latency (how long a time each test takes)
-- Test prevention (the failure of tests to run on particular targets)
+- Latency (how long a time each tool takes to run its tests)
+- Test prevention (the failure of tools to run on particular targets)
 - Logging (browser messaging, including about document errors, during testing)
 
 ## Code organization
@@ -72,7 +78,7 @@ The main directories containing code files are:
 - package root: main code files
 - `tests`: files containing the code defining particular tests
 - `procs`: shared procedures
-- `validation`: code and artifacts for the validation of Testaro
+- `validation`: code and artifacts for the validation of the Testaro tool
 
 ## System requirements
 
@@ -104,18 +110,14 @@ Once you have done that, you can install Testaro as you would install any `npm`
 
 However, if the Playwright dependency is ever updated to a newer version, you must also reinstall its browsers by executing the statement `npx playwright install`.
 
+To run Testaro after installation, provide the environment variables described below under “Environment variables”.
+
 ## Payment
 
 All of the tests that Testaro can perform are free of cost, except those performed by the Tenon and WAVE tools. The owner of each of those tools gives new registrants a free allowance of credits before it becomes necessary to pay for use of the API of the tool. The required environment variables for authentication and payment are described below under “Environment variables”.
 
 ## Process objects
 
-### Introduction
-
-A _job_ is an object containing instructions for Testaro.
-
-A _report_ is a job with properties added by Testaro, describing the results.
-
 ### Jobs
 
 Here is an example of a job:
@@ -123,7 +125,7 @@ Here is an example of a job:
 ```javascript
 {
   id: 'be76p-ts25-w3c',
-  what: 'Test host with alfa',
+  what: 'Test W3C with 2 alfa rules',
   strict: true,
   timeLimit: 65,
   acts: [
@@ -141,7 +143,8 @@ Here is an example of a job:
     {
       type: 'test',
       which: 'alfa',
-      what: 'Siteimprove alfa tool'
+      what: 'Siteimprove alfa tool',
+      rules: ['y', 'r25', 'r71']
     }
   ],
   sources: {
@@ -158,30 +161,103 @@ Here is an example of a job:
 }
 ```
 
-This job contains three `acts`, telling Testaro to:
+This job contains three _acts_, telling Testaro to:
 1. open a page in the Chromium browser
 1. navigate to a specified URL
-1. perform the tests of the `alfa` tool on that URL
+1. perform two of the tests of the `alfa` tool (the tests for rules `r25` and `r71`) on that URL
 
 Job properties:
-- `id`: This is a string consisting of alphanumeric ASCII characters and hyphen-minus (-), intended to be unique. When the above example job is saved as a JSON file, the file name is `be76p-ts25-w3c.json`. Typically, a job is created from a _script_, and the job ID adds a timestamp prefix and a target suffix to the script ID. Here the script ID would have been `ts25`.
-- `what`: This is a description of the job.
-- `strict`: This is `true` or `false`, indicating whether _substantive redirections_ should be treated as failures. These are redirections that do more than add or subtract a final slash. For example, if `strict` is true, a redirection from `xyz.com` to `www.xyz.com` or to `xyz.com/en` will abort the job.
-- `timeLimit`: This property is the number of seconds allowed for the execution of the job.
-- `acts`: This is an array of the acts to be performed. Acts are documented below.
-- `sources`: This object has properties describing where the job came from:
-   - `script`: This is the ID of the script from which the job was made, if it was made from a script, or is otherwise an empty string. Other applications, such as Testilo, can make jobs from scripts. When Testilo creates a job, the job inherits its `id`, `what`, `strict`, `timeLimit`, and `acts` properties from the script. However, Testilo can create multiple jobs from a single script, replacing acts of type `placeholder` with one or more target-specific acts. Examples of scripts can be found in the Testilo package.
-   - `batch`: If the job was one of a set of jobs created by a merger of a script and a batch of targets, this property’s value is the ID of the batch, or otherwise is an empty string.
-   - `target`: If the job was made from a script with placeholder acts, this property describes the target whose target-specific acts have replaced the placeholder acts. Otherwise `target` is an empty object. Testilo also uses the `id` property of the target as the third segment of the job ID.
-   - `requester`: This string is the email address to receive a notice of completion of the running of the job.
-- `creationTime`: This is the time when the job was created.
-- `timeStamp`: This string is a compact representation of the job creation time, suitable for inclusion in the ID of the job.
+- `id`: a string uniquely identifying the job.
+- `what`: a description of the job.
+- `strict`: `true` or `false`, indicating whether _substantive redirections_ should be treated as failures. These are redirections that do more than add or subtract a final slash.
+- `timeLimit`: the number of seconds allowed for the execution of the job.
+- `acts`: an array of the acts to be performed (documented below).
+- `sources`: an object describing where the job came from:
+   - `script` (optional): the ID of the script from which the job was made.
+   - `batch` (optional): a set of targets (URLs) from which the target of this job was drawn.
+   - `target` (optional): an object describing the target being tested by this job.
+   - `requester` (optional): the email address that should receive a notice of completion of the job.
+- `creationTime`: the time when the job was created.
+- `timeStamp`: a string unique to this job.
 
 ### Reports
 
-A _report_ is a copy of a job file. It begins as a pure copy. Testaro adds data to it as Testaro runs the job. Specifically, Testaro:
-- Adds a `jobData` property and populates it with data about the job.
-- Adds properties to the acts, describing the results of the performance of the acts.
+#### Introduction
+
+While each tool produces a _tool report_ of the results of its tests, Testaro also produces a _job report_, combining all of the tool reports of a job.
+- Tools append their reports to their acts in a job. For example, if one act in a job specifies some Continuum tests to be run, Continuum appends its report to that act. In that way, the act now describes not only the Continuum tests that were run, but also the results of those tests.
+- Testaro further elaborates a job by reporting comprehensive results there. Testaro can add more facts to each of the tool reports and also adds whole-job facts, in a `jobData` property, to the job. Testaro thereby converts the job to a job report.
+
+#### Formats
+
+##### Tool formats
+
+The tools listed above as dependencies write their tool reports in various formats. They differ in how they organize multiple instances of the same issue, how they classify issue severity and certainty, how they point to the locations of issue instances, how they name issues, etc.
+
+Integrating reports from 10 different tools is a complex task, as analyzed in [“Accessibility Metatesting”](https://arxiv.org/abs/2304.07591). The diversity of their reporting formats makes the task more complex than it would otherwise be.
+
+##### Standard format
+
+Testaro helps overcome this format diversity by offering to represent the main facts in the report of each tool in a single standardized format.
+
+If the `STANDARD` environment variable has the value `also` (which it has by default) or `only`, Testaro converts some data in each tool report to a standard format. That permits you to ignore the format idiosyncrasies of the tools. If `STANDARD` has the value `also`, the job report includes both formats. If the value is `only`, the job report includes only the standard format. If the value is `no`, the job report includes only the original format of each tool.
+
+The standard format of each tool report has two properties:
+- `totals`: an array of 4 integers, representing the counts of issue instances classified by the tool into 4 ordinal degrees of severity. For example, `[2, 13, 0, 5]` would mean that the tool reported 2 instances at the lowest severity, 13 at the next-lowest, none at the third-lowest, and 5 at the highest.
+- `instances`: an array of objects describing facts about issue instances reported by the tool. Insofar as each tool permits, this object has these properties:
+    - `issueID`: a code identifying the issue
+    - `what`: a description of the issue
+    - `ordinalSeverity`: how the tool ranks the severity of the instance, on a 4-point ordinal scale
+    - `location`: an object with three properties:
+        - `doc`: whether the source (`source`) or the browser rendition (`dom`) was tested
+        - `type`: the type of location information provided by the tool (`line`, `selector`, or `xpath`)
+        - `spec`: the location information
+    - `excerpt`: some or all of the code
+
+The original result of a test act is recorded as the value of a `result` property of the act. The standard-format result is recorded as the value of the `standardResult` property of the act. Its format is shown by this example:
+
+``` javascript
+standardResult: {
+  totals: [2, 0, 1],
+  instances: [
+    {
+      issueID: 'rule01',
+      what: 'button type invalid',
+      ordinalSeverity: 0,
+      location: {
+        doc: 'dom',
+        type: 'line',
+        spec: 32
+      },
+      excerpt: '<button type="link"></button>'
+    },
+    {
+      issueID: 'rule01',
+      what: 'button type invalid',
+      ordinalSeverity: 1,
+      location: {
+        doc: 'dom',
+        type: 'line',
+        spec: 145
+      },
+      excerpt: '<button type="important">Submit</button>'
+    },
+    {
+      issueID: 'rule02',
+      what: 'link href empty',
+      ordinalSeverity: 3,
+      location: {
+        doc: 'dom',
+        type: 'selector',
+        spec: '#helplink'
+      },
+      excerpt: '<a id="helplink" href>help</a>'
+    }
+  ]
+}
+```
+
+If a tool has the option to be used without itemization and is being so used, the `instances` array will be empty.
 
 ### Acts
 
@@ -264,13 +340,13 @@ This act causes Testaro to alter the `display` and `visibility` style properties
 
 An act of type `test` performs operations and reports a result. The result may indicate that a page passes or fails requirements. Typically, accessibility tests report successes and failures. But a test in Testaro is defined less restrictively, so it can report any result. As one example, the Testaro `elements` test reports facts about certain elements on a page, without asserting that those facts are successes or failures.
 
-The `which` property of a `test` act identifies the operations to perform. If the value of `which` is the name of one of the tools, such as `alfa`, then the operations are some or all of the tests of that tool. If the value is the name of a Testaro test, then the operations are those of that single Testaro test. Thus, a single `test` act may specify performing anything from a single test to hundreds of tests.
+The `which` property of a `test` act identifies the operations to perform. The value of `which` is the name of one of the tools, such as `alfa`.
 
 ###### Configuration
 
 Every test in Testaro must have:
 - a property in the `tests` object defined in the `run.js` file, where the property name is the name of the test and the value is a description of the test
-- a `.js` file, defining the test, in the `tests` directory, whose name base is the name of the test
+- a `.js` file, defining the operation of the tool, in the `tests` directory, whose name base is the name of the tool
 
 The `actSpecs.js` file (described in detail below) contains a specification for any `test` act, namely:
 
@@ -284,13 +360,13 @@ test: [
 ],
 ```
 
-That means that a test (i.e. an act with a `type` property having the value `'test'`) must have a string-valued `which` property naming a test and may optionally have a string-valued `what` property describing the test.
+That means that a test act (i.e. an act with a `type` property having the value `'test'`) must have a string-valued `which` property naming a tool and may optionally have a string-valued `what` property describing the tool.
 
-If a particular test either must have or may have any other properties, those properties must be specified in the `tests` property in `actSpecs.js`.
+If a particular test act either must have or may have any other properties, those properties are specified in the `tests` property in `actSpecs.js`.
 
 ###### Examples
 
-An example of a `test` act invoking a **tool** is:
+An example of a `test` act is:
 
 ```json
 {
@@ -301,26 +377,80 @@ An example of a `test` act invoking a **tool** is:
 }
 ```
 
-In this case, Testaro runs the WAVE test with report type 1.
+Most tools allow you to decide which of their _rules_ to apply. In effect, this means deciding which of their tests to run, since each test is considered a test of some rule. The act example given above,
 
-An example of a `test` act invoking a **Testaro** test is:
+```javaScript
+{
+  type: 'test',
+  which: 'alfa',
+  what: 'Siteimprove alfa tool',
+  rules: ['y', 'r25', 'r71']
+}
+```
 
-```json
+specifies that the tests for rules `r25` and `r71` of the `alfa` tool are to be run. If the `'y'` in the `rules` array were e`'n'` instead, the act would specify that all the tests of the `alfa` tool **except** those for rules `r25` and `r71` are to be run.
+
+One of the tools that allows rule selection, Testaro, has some rules that take additional arguments. As prescribed in `actSpecs.js`, you can pass such additional arguments to the `reporter` functions of those Testaro tests with an `args` property. Example:
+
+```javaScript
 {
-  "type": "test",
-  "which": "motion",
-  "delay": 1500,
-  "interval": 2000,
-  "count": 5,
-  "what": "test for motion on the page"
+  type: 'test',
+  which: 'testaro',
+  what: 'Testaro tool',
+  rules: ['y', 'hover', 'focInd'],
+  args: {
+    hover: [20],
+    focInd: [false, 300]
+  }
 }
 ```
 
-In this case, Testaro runs the `motion` test with the specified parameters.
+This act specifies that the Testaro tests `hover` is to be run with the additional argument `20`, and `focInd` with the additional arguments `false` and `300`.
+
+###### Expectations
+
+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.
+
+For example, a `test` act might have this `expect` property:
+
+```javaScript
+'expect': [
+  ['total.links', '=', 5],
+  ['total.links.underlined', '<', 6],
+  ['total.links.outlined'],
+  ['docLang', '!', 'es-ES'],
+  ['items.3.tagName', '=', 'BUTTON']
+]
+```
+
+That would state the expectations that the `result` property of the act will have:
+- a `total.links` property with the value 5
+- a `total.links.underlined` property with a value less than 6
+- **no** `total.links.outlined` property
+- a `docLang` property with a value different from `es-ES`
+- an `items[3].tagName` property with the value `'BUTTON'`
+
+The first item in each array is an identifier of a property within the `result` object. 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.
+
+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.
+
+The second item in each array, if there are 3 items, is an operator, drawn from:
+- `<`: less than
+- `=`: equal to
+- `>`: greater than
+- `!`: unequal to
+- `i`: includes
+- `e`: equivalent to (parsed identically as JSON)
+
+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.
+
+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.
+
+When a `test` act has an `expect` property, the result for that act has an `expectations` property reporting whether the expectations were satisfied. The value of `expectations` is an array of objects, one object per expectation. Each object includes a `property` property identifying the expectation, and a `passed` property with `true` or `false` value reporting whether the expectation was satisfied. If applicable, it also has other properties identifying what was expected and what was actually reported.
 
 ###### Continuum
 
-The `continuum` tests makes use of the files in the `continuum` directory. The test inserts the contents of all three files into the page as scripts and then uses them to perform the tests of the Continuum tool.
+The `continuum` tests makes use of the files in the `continuum` directory. The tool inserts the contents of all three files into the page as scripts and then uses them to perform the tests.
 
 Level Access on 22 August 2022 granted authorization for the copying of the `AccessEngine.community.js` file insofar as necessary for allowing Continuum community edition tests to be included in Testaro.
 
@@ -347,11 +477,9 @@ results.label = results.label.replace(/:/g, '-');
 
 These changes were proposed as pull requests 1333 and 1334 (https://github.com/IBMa/equal-access/pulls).
 
-If you choose to invoke the `ibm` tests with the `withNewContent` property specified, you will choose whether the tested content is the content of the existing page or is retrieved anew with the document URL. Typically, both methods succeed and deliver similar results. However, sometimes one method succeeds and the other fails, or one method reports more violations than the other does. In those cases, most often the success, or the larger violation count, arises from the existing page (`withNewContent: false`).
-
 ###### HTML CodeSniffer
 
-The `htmlcs` tests make use of the `htmlcs/HTMLCS.js` file. That file was created, and can be recreated if necessary, as follows:
+The `htmlcs` tool makes use of the `htmlcs/HTMLCS.js` file. That file was created, and can be recreated if necessary, as follows:
 
 1. Clone the [HTML CodeSniffer package](https://github.com/squizlabs/HTML_CodeSniffer).
 1. Make that package’s directory the active directory.
@@ -383,7 +511,7 @@ The changes in `htmlcs/HTMLCS.js` are:
 
 ###### QualWeb
 
-A `qualWeb` test act performs the ACT rules, WCAG Techniques, and best-practices tests of QualWeb. Only failures and warnings are included in the report. The EARL report of QualWeb is not generated, because it is equivalent to the report of the ACT rules tests.
+The `qualWeb` tool performs the ACT rules, WCAG Techniques, and best-practices tests of QualWeb. Only failures and warnings are included in the report. The EARL report of QualWeb is not generated, because it is equivalent to the report of the ACT rules tests.
 
 ###### Tenon
 
@@ -413,7 +541,7 @@ Example:
   }
 ```
 
-The reason for this is that the Tenon API operates asynchronously. You ask it to perform a test, and it puts your request into a queue. To learn whether Tenon has completed your test, you make a status request. You can continue making status requests until Tenon replies that your test has been completed. Then you submit a request for the test result, and Tenon replies with the result. (As of May 2022, however, status requests were observed to misreport still-running tests as completed. The `tenon` test act works around that by requesting only the result and using the response to determine whether the tests have been completed.)
+The reason is that the Tenon API operates asynchronously. You ask it to perform a test, and it puts your request into a queue. To learn whether Tenon has completed your test, you make a status request. You can continue making status requests until Tenon replies that your test has been completed. Then you submit a request for the test result, and Tenon replies with the result. (As of May 2022, however, status requests were observed to misreport still-running tests as completed. The `tenon` test act works around that by requesting only the result and using the response to determine whether the tests have been completed.)
 
 Tenon says that tests are typically completed in 3 to 6 seconds but that the latency can be longer, depending on demand.
 
@@ -494,7 +622,7 @@ The requirement `which: [true, 'string', 'hasLength', 'substring of the link tex
 
 In most cases, the array has length 4:
 - 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.
-- 1. What format must the property value have (`'string'`, `'array'`, `'boolean'`, or `'number'`)?
+- 1. What format must the property value have (`'string'`, `'array'`, `'boolean'`, `'number'`, or `'object'`)?
 - 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.
 - 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.
 
@@ -508,38 +636,6 @@ The validity criterion named in item 2 may be any of these:
 - `'isWaitable'`: is `'url'`, `'title'`, or `'body'`
 - `'areStrings'`: is an array of strings
 
-Any `test` act can also (in addition to the requirements in `actSpecs.js`) 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 test.
-
-For example, a `test` act might have this `expect` property:
-
-```javaScript
-'expect': [
-  ['total.links', '=', 5],
-  ['total.links.underlined', '<', 6],
-  ['total.links.outlined'],
-  ['docLang', '!', 'es-ES']
-]
-```
-
-That would state the expectation that the `result` property of the act for that test in the report will have a `total.links` property with the value 5, a `total.links.underlined` property with a value less than 6, **no** `total.links.outlined` property, and a `docLang` property with a value different from `es-ES`.
-
-The first item in each array is an identifier of a property within the `result` property. 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. For example, `items.1.attributes.0` references the first element of the array that is the `attributes` property of the object that is the second element of the array that is the `items` property of `result`. (In JavaScript, this would be written `items[1].attributes[0]`, but in the `expect` property all property names are `.`-delimited.)
-
-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.
-
-The second item in each array, if there are 3 items in the array, is an operator, drawn from:
-- `<`: less than
-- `=`: equal to
-- `>`: greater than
-- `!`: unequal to
-- `i`: includes
-
-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.
-
-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.
-
-When a `test` act has an `expect` property, the result for that act has an `expectations` property reporting whether the expectations were satisfied. The value of `expectations` is an array of objects, one object per expectation. Each object includes a `property` property identifying the expectation, and a `passed` property with `true` or `false` value reporting whether the expectation was satisfied. If applicable, it also has other properties identifying what was expected and what was actually reported.
-
 ## Execution
 
 ### Introduction
@@ -673,7 +769,7 @@ DEBUG=false
 
 ### Validators
 
-Testaro and its custom tests can be validated with the _executors_ located in the `validation/executors` directory.
+Testaro and the tests of the Testaro tool can be validated with the _executors_ located in the `validation/executors` directory.
 
 The executor for a single test is `test`. To execute it for any test `xyz`, call it with the statement `npm test xyz`.