TesterKit

Your platform for hardware test and measurement.

Write ordinary pytest. Every measurement lands recorded, checked against spec, and ready to query. Free and open source.

What it takes to test hardware

Mapping product specs to a test plan. Designing stations and selecting instruments. Developing test code across multiple test phases. Verifying measurements against spec-traced limits. Analyzing results in their captured context.

You write the test. TesterKit helps with the rest.

Change nothing, get a test record

An ordinary pytest test. Your driver, your fixture, plain assert:

def test_rail_within_spec(psu, dmm):
    psu.set_voltage(5.0)
    psu.enable_output()
    assert 3.2 <= dmm.measure_dc_voltage() <= 3.4

Install TesterKit and run it again. The test is untouched, and the run files itself:

$ testerkit show 14cfbe7d
Test Run: 14cfbe7d-30d0-4334-b59c-0c04f7576740
  UUT Serial: SN0413
  Outcome: passed
  Started: 2026-07-25T18:39:00-0600
  Steps: 2
  Measurements: 0 (0 failed)

Step Results:
   0. test_rail_within_spec: passed
   1. test_rail_holds_across_input: passed

Traceable history per serial, for nothing. Now read the last line of that header. Pytest checked 3.2 <= v <= 3.4 and threw the number away. It has no concept of a measurement, so there was nothing to file.

Give it one, and the same run comes back with the readings in it:

    verify("v_rail", dmm.measure_dc_voltage(), limit=V_RAIL)

  Measurements: 6 (0 failed)

Measurements:
  v_rail: 3.31 V [passed]

Every run adds to that history. Run testerkit serve and it is a browser away — every reading for a characteristic, plotted against the limits it was checked against:

TesterKit's measurement explorer: readings for one characteristic plotted over successive runs, with limit-low and limit-high bands drawn across the chart.
The operator UI also launches tests, follows them live, and answers yield, Pareto, and Ppk across the run history.

And that’s the smallest thing it does. The same tests grow into limits traced to the part spec, benches described in text your ops team can edit, live operator screens, parallel test sites, and a production floor’s worth of results your analysts can query. None of it gets in your way before you want it.

Run your first test →or read the seven worked examples →

What you get

Principles

Batteries included, nothing imposed

Storage, validation, querying, and a UI come decided and wired together — no stack to assemble to get a working platform. The choices that touch your own workflow stay yours.

Configuration is text

Stations, parts, fixtures, profiles are YAML. Reviewable on a PR, editable by anything that handles text.

AI-ready, not AI-dependent

Agents can drive every operation through MCP or the CLI. Nothing about the platform requires one.

Runs anywhere, including offline

Local execution by default. No required server, no required account, no cloud dependency. Works on an air-gapped bench.

Open source, Apache-2.0

The code is yours to read, run, fork, and extend. No paid tier of the same software waiting to take it over once you depend on it.

Try it

From nothing to passing tests

pip install testerkit
testerkit init my_project --starter && cd my_project
pytest

Three tests pass against simulated instruments, and their measurements are already recorded and checked against the part spec. No bench required to get here.

Free and open source, Apache-2.0. The PyPI distribution and the Python import are both testerkit.

Or run it in your browser — no install

Open in Codespaces

A browser sandbox — mock instruments, the operator UI, analytics, and AI. Real instrument control needs a local install.

Quick StartDocumentationSource on GitHub →

Apache-2.0 · pre-1.0 · public on GitHub. APIs may shift before 1.0; pin a version, fork if you have to. Your tests are ordinary pytest; your results are open files on your disk.