Concepts and Glossary
The OpenHTF vocabulary — DUT, station, test, phase, measurement, validator, plug, attachment, test record, output callback — each defined in one paragraph with a link to its page.
Last updated · Verified with OpenHTF 1.6.1
OpenHTF uses a small, fixed vocabulary. Most of it comes from the upstream README's "Nomenclature" section; the rest are terms you meet in the API. Terms are listed in the order you encounter them writing a test.
DUT (Device Under Test)
The physical unit being tested — a board, a module, an assembled product. Also called UUT (Unit Under Test) in some industries; OpenHTF's API says DUT. Every run is tied to one DUT through its DUT ID, normally the serial number, stored as dut_id in the record. Device Under Test →
Station
The computer, fixture and instruments a test runs on. Identified by station_id in every record (defaults to the hostname). One station usually runs one test script at a time; a line has many stations. Configuration → · Multi-station →
Test
An htf.Test(...) object: an ordered collection of phases plus test-wide options and metadata. Calling test.execute() runs the sequence once against one DUT and produces one test record. Phases → · Test Options →
Phase
One step of a test: a Python function that receives the test API object, does work, and returns a PhaseResult (CONTINUE, STOP, REPEAT, SKIP, FAIL_AND_CONTINUE, FAIL_SUBTEST). Phases carry measurements, plugs and options via decorators. Phases →
Phase group
A PhaseGroup of setup, main and teardown phases. Teardown runs whenever setup succeeded, even if main failed — the try/finally of hardware tests. Phase Groups →
Subtest
A named sequence of phases whose failure (FAIL_SUBTEST) does not stop the rest of the test. Lets one run report independent results for, say, Wi-Fi and Bluetooth. Subtests →
Checkpoint
A node in the sequence that stops the test (or, with action=FAIL_SUBTEST, fails the subtest) if earlier phases failed. Placed before expensive phases. Checkpoints →
Measurement
A named value a phase promises to record, declared with @htf.measures(htf.Measurement("name")...). May carry a unit, a docstring, dimensions and validators. Unset measurements fail the phase unless allow_unset_measurements is on. Measurements →
Validator
A rule attached to a measurement that decides PASS or FAIL: in_range, equals, matches_regex, within_percent, or any callable. Marginal limits flag values that pass but sit near the edge. Validators reference →
Unit
A UnitDescriptor (name, UNECE code, suffix) attached with .with_units(units.VOLT). Stored in the record so downstream tools can label and convert values. Units reference →
Dimension
An input axis of a multi-dimensional measurement (time, frequency, channel). A measurement with dimensions stores a table of coordinates → value instead of a scalar. Multi-dimensional measurements →
Monitor
A background thread that samples a function at a fixed interval while a phase runs, producing a time-series measurement. Monitors →
Plug
A class inheriting BasePlug that wraps a resource — instrument, DUT interface, operator prompt. Instantiated once per test before the first phase that needs it, torn down after the test. Injected into phases with @htf.plug(name=PlugClass). Plugs →
Operator UI
The browser interface served by station_server.StationServer: live phases and measurements, prompts, attachments, logs and per-station history. Operator UI →
Prompt
A question to the operator via the UserInput plug — a text field or an Okay button, in the console and in the Operator UI. prompt_for_test_start() is the prompt that asks for the DUT ID. User Input plug →
Diagnosis
A structured result (Diagnosis with a DiagResultEnum value) produced by a diagnoser after a phase or the whole test, classifying what happened — "over-voltage", "board defective". Branches and checkpoints can condition on diagnoses. Diagnoses →
Attachment
A file or binary blob stored in the record alongside a phase: a scope screenshot, a UART log, a calibration table. Attachments →
Test record
The TestRecord produced by every run: dut_id, station_id, outcome (PASS, FAIL, ERROR, TIMEOUT, ABORTED), timestamps, phases[] with their measurements and attachments, log_records, metadata, diagnoses. Test Record → · JSON format →
Output callback
A callable that receives the finished TestRecord. OutputToJSON writes a file; ConsoleSummary prints failures; TofuPilot's upload() sends it to a database. Several can run per test. Output Callbacks →
Configuration
Key/value settings declared with CONF.declare(...) and loaded from YAML/JSON, --config-value flags or code. Used for ports, addresses, limits and station identity. Configuration →
Related
Tutorial
Step-by-step OpenHTF tutorial. Build a resistor test with a power supply and multimeter plug (PyVISA, with a simulation mode), add a measurement with limits, read the console summary, and upload the record.
Phases
Discover how to define and execute test phases using OpenHTF, including phase creation, phase results, and phase options with detailed examples.