TTestFlow/Docs
Open TestFlow
Product guide/The builder/Executor

The builder

Executor

Where tests run. Live progress, a streaming log, measurements as they arrive, and a queue when you have several tests to get through.

The Executor pane before a run: the Script Executor header, a Select tests action, Overview and History tabs, an empty steps list and an empty execution log.
The Executor before a run. Pick a test, choose the mode, and the console below fills in as it goes.
The Executor mid-run: a run bar with the workflow name, a Running badge and Pause and Stop buttons, a progress bar at 59 percent, a steps rail with ticked and pending steps, a live execution log, and a loop counter at the bottom left.123456
  1. 1Status. The workflow being run, and a badge for the state it is in.
  2. 2Progress, driven by the running package itself rather than estimated.
  3. 3The steps rail. Ticked steps are done, the spinner is the step executing now, and hollow ones are still ahead.
  4. 4Loop counter and live values. Which iteration, and what each variable and measurement currently reads.
  5. 5The execution log, streaming. Auto-scroll, a clear, and an event count sit in its header.
  6. 6Pause and Stop. A stopped run is reported as stopped, never as a failure and never as a pass.
One run in flight. Everything on this screen comes from the package executing on your machine.

The two run modes

The green run split button, reading Simulate, with a chevron on its right for choosing the run mode.
The button runs the mode it shows. The chevron switches between Simulate and Run on my bench.

Simulate

No hardware

  • Runs in your browser against synthetic data that follows the real workflow semantics.
  • Loops iterate, variables sweep, each measurement records a value.
  • Proves the sequence is coherent. Proves nothing about your hardware.

Run on my bench

Real instruments, over VISA

  • Executes the generated package through the desktop app on your machine.
  • Real readings, evaluated against your limits as they are recorded.
  • The first time, TestFlow offers the desktop app download.

The split button runs the mode shown; the arrow beside it switches mode. Run in the main toolbar does the same thing and switches you to this pane.

What you see during a run

The steps rail during a run: ticked entries for a power supply, a loop, a second power supply and a delay, a spinner on an oscilloscope measurement step, and hollow entries below it.
The steps rail. The fastest way to see where a run stalled.
A loop counter reading Loop 1 with a progress bar at 6 of 9, and live values for N4(Measurement) at 0.998 and vin at 3.5.
Live values: the iteration, and what each column currently reads.
The Executor run bar: the workflow name, a Running badge, a Sample run badge, a Test Report chip reading Preparing, Pause and Stop buttons, and a progress bar underneath showing 6 seconds elapsed and 59 percent.
The run bar and its progress. The badges say what kind of run this is, which is how you tell a simulation from a bench run at a glance.
The execution log header: the words Execution log, an Auto-scroll checkbox, a Clear action, and a count reading 60 events.
The log view is capped for performance. The complete log is on disk in the package's Output folder.
ElementShowsNotes
ProgressPercentage complete and a status badge.Driven by the running package, not estimated.
Step railWhich step is executing, and which have completed.The fast way to see where a run stalled.
Action tickerThe specific action in flight.Useful when one step has many actions.
Loop counterIteration number and the current variable values.Confirms the sweep is doing what you asked.
Execution logThe run’s output, live.Capped in the view for performance. The complete log is on disk in Output/.
Measurement dashboardReadings as the results file grows.Cards per measured column, updating a few times a second.
StopEnds the run.A stopped run is reported as stopped, never as a failure and never as a pass.

Running several tests

The Select tests button beside a queue chip naming a queued workflow, with a small cross for removing it.
The queue. Each chip is a queued workflow; the cross drops it.
A pair of tabs in the Executor reading Overview and History.
Overview is the live run. History is every run before it.

Select a test to run opens the queue. Add as many workflows as you want, reorder them, and remove one from the queue with the × on its chip. The run button then shows the count and works through them in order. Queued items are refreshed to their latest saved revision when the run starts, so you are never running yesterday's snapshot.

Opening Executor from a builder session pre-selects the workflow you were just editing, so the common case takes no setup.

Approving generated drivers

If the run would execute an AI-written driver against real hardware for the first time, Executor stops and shows you the code. Approve it to continue. Approval is keyed to the shape of the workflow, so retuning a set-point does not ask again and restructuring the test does.

Importing an existing script

Executor accepts a TestFlow script file dropped onto it, which is how you run something exported from another workspace without rebuilding it.

See also
Results and historySimulate vs benchThe desktop app