Steps¶
A step is the smallest thing a run does. It has a sentence — that is what the test case says — and behind it a definition — that is what actually happens at the bench.
The two are kept apart on purpose. Whoever writes the procedure picks the sentence; the definition behind it is filled in once and reused by every test case that says the same sentence. Change what the output is measured means, and it changes for every test case that says it.
Adding a step¶
Open Test-Editor → Steps in the sidebar — the step files stand in the tree on the left — and press New step.
- Action Type — what it does. See the table below.
- Steps — the sentence, as it will stand in the test case: the output is between 4.9 and 5.1 volts. Beside it you choose its kind: Setup, Action or Check. A sentence may hold any character — an apostrophe (the system's state is {state}), quotes, a backslash: XPressRT writes it so that the step file stays readable for every run.
- Tags — optional; see Tags.
- Description — required. Say what the step does and when to use it. It is what somebody reading the step later has to go on, and what the suggestion list shows.
- Its settings, under Action Configuration, which depend on the action type.
Then it is available to every test case in the workspace.
A step is a Setup, an Action or a Check, and nothing else. And and But are how a test case continues the line above; a step saved as either is refused, and nothing is written. And one sentence is one step: the same sentence under a second kind is refused too, whichever way you try to create it.
Placeholders
A sentence may contain a placeholder in braces, and a test case with variants fills it in per row. the supply is set to {u_set} volts is one step used by three rows at three different voltages.
A placeholder is a name — letters, digits, underscores. Braces that hold anything else are data and stay as they are: a test case line may read rmCAN sends {"x":10, "y":0} to PatientPositioning, and nothing is substituted there. That is the normal case for software and module tests, and such a message does not have to be moved into a variants column.
What a step can do¶
Filled in here:
| Action | What happens at the bench |
|---|---|
| Ask the operator | Shows a question or an instruction and waits. Confirm only, Yes/No, or a typed answer. It can show a picture with it, uploaded in the step form. |
| Read data points | Asks for one or more readings, records them and judges them against limits. It can show a picture with it, like a question. |
| Set data points | Says what to set, and records what was reached. |
| Record a serial number | Asks for the serial number of the unit — once per procedure or once per test case. |
| Wait | Pauses for a fixed time. |
A data point can hold a record or a list instead of one value. Read, Set and Request then show a row per field under the point: what a field has to be, its limits, the value to set — see Records and lists.
Written by you: Python. The step's body is code in your workspace, run on your own machine by a small program you start alongside XPressRT — the runner. See Python steps.
Or the same step as blocks: one sentence per thing it does, turned into the Python that runs. Blocks run in the browser, so they need no runner. See Blocks.
Settings every step has¶
If it fails decides what happens after a failed step:
- Stop this test case — the rest of this test case is skipped. The next test case still runs.
- Record the failure and carry on — the next step runs anyway.
Neither of them turns a failed step green, and neither ends the run.
Error code and Error message are what the report shows when the step
fails: a short code of your own, such as E700, and a sentence a reader
understands — The output was outside its limits. On the Steps page the message
is listed as Recorded as.
Two check boxes decide whether the operator is asked to write something down: for a defect report when the step fails, and for a proof when it passes. Their wording depends on the action type; on the Steps page they read Asks for a defect report and Asks for a proof report. See Running a test.
The description, and changing it¶
A step's description is what a person reads before they approve it, and what an assistant reads before it writes the step into a test case. It is written when the step is created — and it used to be fixed for good after that, which is how a workspace ends up with descriptions that no longer describe anything.
It can be changed now: in the step's settings, or by an assistant with
describe_step. The sentence, the body and everything a test case refers to
stay exactly as they are.
A step built from blocks carries the same text twice — here, and as PURPOSE
in its block file. They are written together, so there is one text in two
places rather than two texts. Where they differ — somebody edited the block
file by hand — the build says so; see Blocks.
Trying a step out¶
Test Step, at the top of the step's settings, runs the step on its own. You do not need a test case for it: it works from the Steps page as well.
If the sentence has placeholders, a dialog Values for this trial asks what they should hold first. Opened from a test case with variants, the fields start with the first row of its table; you can change them, and the trial runs with what you typed. Cancel, and nothing is tried and nothing is changed.
Test Step saves the step and then runs it. Beyond that, a trial leaves nothing behind: the values you typed are not saved — the step keeps its placeholders — and the throwaway procedure it runs in is not left in your procedure list.
A Python step needs its runner for a trial, and the button stays disabled while the runner is not running. A step written as blocks does not: it is tried in the browser.
Renaming and deleting a step¶
A step's sentence is what the test cases say, so changing it is not a private matter. If test cases use the step, renaming it shows This step is in use: how many lines use it, in which procedures, and the lines themselves. You choose Update them too, which rewrites those lines to the new sentence, or Rename only the definition, which leaves them with the old text — and they will be reported as undefined on the next run. If the new sentence has a placeholder more or less than the old one, the dialog says which lines cannot be carried over.
Deleting works the same way. For a step nothing uses, you only confirm. A step in use shows the lines that use it, and you choose Delete them everywhere or Leave them in the test cases — where they then match nothing. A test case left with no steps at all is named afterwards, because a test case with no steps passes.
When a line says the steps could not be loaded¶
In a test case, a line with no step behind it says No matching step. That is a finding about your test case.
If the page could not fetch the list of steps at all, every line would look like that, and none of them would be true. Then the lines say Steps could not be loaded, so this line was not checked. Reload the page. Nothing is wrong with the test case; reload the page.
Reading it back¶
The Steps page shows every step with its sentence, its tags, its description and its settings in plain words — not its code: what the operator will be shown, what counts as a failure, what the run records. A step that reads data points names each one with its limits; a step that sets them names each one with the value it is set to, and whether the value actually reached is recorded; on a record point each of them field by field. A step written by hand, rather than through the step window, says Written by hand: no settings recorded.