Configuration
Reference for everything a run accepts. For a first run, Getting started covers the two required parameters and a minimal example.
Execution parameters
| Parameter | Required | Meaning |
|---|---|---|
instructions |
yes | The test cases to produce and what each must cover. |
apDirectory |
yes | Where the finished package is published. If a package is already there, it is extended rather than replaced. |
stepApiKey |
for central runs | API key for the Step instance the generated package is executed against. |
triggerAutomationPackageExecution |
no, default false |
Execute the generated package centrally and heal it if that run fails. |
triggerAutomationPackageStabilityCheck |
no, default false |
Execute the package centrally several times and gate on how many passed. |
enableClassification |
no, default true |
Set to false to require every test case to declare its purpose rather than letting the agent infer it. |
By default a run generates, executes and heals the package locally and never touches a Step instance. The two central phases are opt-in and independent.
Test case fields
| Field | Required | Meaning |
|---|---|---|
name |
yes | The test case name. For create it becomes the Step plan name and is used verbatim. For the other modes it references an existing test case. |
spec |
yes | What the test case covers, in plain text: the steps, the data, the application URL. |
mode |
yes | create, extends or regenerate. See below. |
hints |
no | Guidance for this test case, carried through design, implementation and healing. |
hints (top level) |
no | Guidance for the whole run. |
The three modes
| Mode | Effect |
|---|---|
create |
A new test case under the name you gave it. |
extends |
The named test case already exists. Its journey is kept and the new steps are added to it. |
regenerate |
The named test case already exists. Its journey is replaced by the new spec, under the same name. |
A reference to a test case that does not exist fails immediately rather than becoming a wrong result later.
Hints
Hints are optional free text for guidance the agent cannot infer, such as a brittle widget to wait for or a selector convention to follow:
{
"testCases": [
{ "name": "Guest checkout for a MacBook",
"spec": "...",
"mode": "create",
"hints": "the cart drawer animates, wait for the line item rather than the badge" }
],
"hints": "[all] the staging environment is slow, be generous with waits"
}
A line can be prefixed to target one stage of the run, or [all] for the whole run. Without any prefix the whole text is treated as one note for every stage.
Limitations
- A test case declares itself as functional testing or RPA. Load testing and monitoring are recognised but not yet accepted as declared use cases. This does not limit the package that comes out, which is ordinary Step automation and can be used for those disciplines like any other.
- Test cases cannot be deleted through
instructions.removeis rejected explicitly rather than ignored.