Open Source Register
The Dokime mark: a salamander standing in flame.

Dokime · Test Automation

Test Automation Your Whole Team Can Run.

Dokime runs repeatable hardware and software test procedures, records everything that happened while they ran, and hands you a report.

It is one interface over a whole framework of test automation and data collection: an author names only what a step does, a tester presses start, and everything between the two is work the platform has already done.

Get the InstallerOpen the Repository

Rust · Pre-1.0 · Windows and Linux

  • +Bench Tests
  • +Device Qualification
  • +Manufacturing Checks
  • +Integration Campaigns
Plate I. What One Run Hands BackReport
Procedure
Which test ran, and the exact version of it.
Inputs
The parameters the run was given, frozen at the moment it started.
Measurements
Every sample the instruments produced, with its own timestamp.
Decisions
What the operator was asked, and what they answered.
Evidence
Logs, captures, and exports, held with the run that made them.
Verdict
Passed, failed, or indeterminate, and the rule that decided it.

One file. It opens in a browser with no server and no account.

Maturity
Pre-1.0
License
MIT OR Apache-2.0
Platforms
Windows and Linux

Before and After

Manual Versus Dokime

Nothing about the engineering changes. What changes is how much of it a person has to carry by hand.

Where the procedure lives

TodayIn a document, a spreadsheet, and somebody's notes, none of which agree.

With DokimeIn one catalog, with its parameters and the rule that decides the result.

How a run starts

TodayAn engineer sets each condition by hand and stays at the bench while it runs.

With DokimeAn operator picks the procedure, confirms the inputs, and presses start.

What gets recorded

TodayWhatever somebody remembered to write down, next to whatever the instruments exported.

With DokimeMeasurements, files, and operator answers, attached to the run that produced them.

When the report exists

TodayDays later, assembled from notes by someone already working on the next job.

With DokimeThe moment the run ends, generated from the run itself.

  • What Survives the Run

    A finished execution keeps its measurements, the operator responses it asked for, the criterion that decided it, and the evidence attached to it. None of that depends on who was standing at the bench.

  • What Two Cycles Have in Common

    A template expands the same declared parameters into the same cases every time. A cycle from March and a cycle from September carry comparable inputs and comparable rows rather than two people's habits.

  • What a Run Records

    Which revision, which specimen, which settings, which operator: each execution already carries them. A tester answers the questions the procedure asks, and is asked for nothing else.

Fig. 1 · A Worked Example

One Charger, Sixty Operating Points

An onboard charger in design validation. Two endurance runs: high-temperature operating endurance, and power-temperature cycling endurance across an operating-point matrix.

Input voltage
3 levels
Output power
4 levels
Ambient temperature
5 levels

3 × 4 × 5 = 60 operating points

60 × 3 repetitions = 180 executions

A person can hold one operating point at a time. A cycle holds the whole matrix, and the matrix is what the requirement actually asks for.

Fig. 1 · The Same 180 ExecutionsIllustration

Setup Time

By HandNone worth naming. The setting up is the running.

With DokimeAbout 10 minutes, composing the cycle from the suite's parameters.

Attention Time

By HandRoughly 8 hours at the bench: set a point, wait for it to settle, read, write it down.

With DokimeNone after the start. The cycle runs unattended and keeps going overnight.

Repetitions

By HandAs many as somebody has hours for, which in practice means one pass.

With DokimeAs many as the schedule allows. Three passes cost the same 10 minutes to plan.

Evidence

By HandA notebook, plus whatever files the instruments happened to export.

With DokimeEvery sample, file, and decision, stored against the execution that produced it.

Illustrative figures, not a measured benchmark. Your bench, your instruments, your numbers.

The Desktop App

The Screens a Tester Uses

One developer writes the procedure, and ten testers push a button. That split is the whole point. A tester never opens a terminal, never edits a file, and never installs a toolchain. They open the app, choose what to run, and watch it happen.

Choose, Set, PreviewPlan
The Plan screen: a catalog of suites on the left, parameters and a preview of the cases on the right.PLANcatalogparameterspreviewevery case, before it runs

Surface 01

Plan

Browse everything the team can run, set the parameters for a cycle, and preview every case it will produce before anything starts.
Steps, Plot, PromptExecution
The Execution screen: a checklist of steps beside a live plot, with an operator prompt waiting under it.EXECUTIONstepsliveoperator prompt

Surface 02

Execution

Watch one case run: the checklist of steps, the measurements plotted as they arrive, and the questions the procedure asks the operator.
CycleSurface 03
The Cycle screen of the Dokime desktop app.

Surface 03

Cycle

The whole planned set at once. What passed, what failed, what is still waiting, and how far through the run is.
Two Runs, Side by SideExplore
The Explore screen: two finished runs plotted over each other, with the evidence each one produced listed beneath.EXPLORErun 14run 15evidencemeasurements

Surface 04

Explore

Go back through finished runs, put them beside each other, and read the measurements and evidence any one of them produced.
Installed, and What They May DoSettings
The Settings screen: the installed plugins, the permissions each one declared, and the folder execution data is written to.SETTINGSinstrumentauthorizedsuiteauthorizedreportingauthorizedexecution data folderoutput

Surface 05

Settings

Install a plugin, choose where execution data is kept, and read exactly what each installed plugin declared it is allowed to do.
One File, No ServerReport
A finished cycle exported as one self-contained file, opening in a browser with nothing running behind it.CYCLEexportreport.htmlno server, no account, no network

The Export

Report

One click turns a finished cycle into a single file that opens in any browser, offline, with no server and no account behind it.

  • Operator Prompts

    When a procedure needs a person, the run pauses and puts the question on screen. The question and the answer both end up in the record.

  • Live Plots

    Measurements stream into time series, histograms, and distributions as they arrive, so a run that is going wrong is visible before it finishes.

  • The Exported Report

    The report is self-contained. It travels by email, sits in a folder, and opens years later without anything to install.

Plate II · What a Run Records

The Record Vocabulary

A template turns its parameters into concrete cases. A cycle holds them. Each execution carries its own measurements, its own criteria, and its own evidence. None of it is a label in a user interface; each term names a durable part of the record.

Plate II. One Case RecordMINI / SIDECAR
Suite
mini.checksThe grouping the cycle was planned from.
Template
mini.checks.pulseIts parameters became immutable inputs at admission.
Steps
start · stream · completeEach phase carries its own result.
Criterion
mini.checks.pulse.acceptanceThe declared rule that decided the outcome.
Channel
mini.pulseTyped rows, sampled every 100 ms.
Records
mini.run.started · mini.run.completedDurable occurrences with a declared contract.

Read from plugins/mini. The report carries the same record offline.

Traceability

Every execution already carries the tool that ran it, the host it ran on, the environment it ran in, and the execution it belongs to. Nobody types those, which is the only reason they are reliable a year later.

Read the Vocabulary
Suite
A grouping of test templates and their execution contract.
Template
A definition that generates one or more concrete test cases from parameters.
Case
A concrete unit of work inside a cycle.
Cycle
The durable aggregate for a planned or running set of cases.
Execution
A run attempt within a cycle, including lifecycle state and output.
Step
A named phase of case execution with a result.
Criterion
A declared validation rule used to decide a result.
Prompt
A runtime request that pauses for an operator-supplied response.
Telemetry Sample
A payload published to a declared channel and stored as a tracked series row.
Record
A durable product occurrence with a declared contract.
Evidence
Structured or file-shaped material attached to product records.
Artifact
Durable bytes stored outside the journal and addressed by metadata.
Traceability
The relationship between tests and requirement-like items or snapshots.

Fig. 2 · Plugins and the Host

The Plugin Host

A plugin is a separate program with its own dependencies and its own vendor libraries. It teaches the platform one thing: an instrument, a stage, a service, a test suite. The host runs them, routes between them, and owns the record none of them can write alone.

Two plugins either side of the Dokime hostThe left plugin contributes test suites, samplers, and listeners. The right plugin contributes custom routes, samplers, and watchers. The host between them carries five duties: cycle execution, route dispatch, plugin supervision, report export, and record admission. Two arrows cross it: a step on the left reaching a route the right plugin registered, and a record published on the right reaching a listener on the left.DOKIME HOSTCycle ExecutionRoute DispatchPlugin SupervisionReport ExportRecord AdmissionPLUGIN ATest SuitesSamplersListenersPLUGIN BCustom RoutesSamplersWatchers121 · a step reaches a route the other plugin registered, and the reply comes back2 · a record is admitted against its contract, stamped, and forwarded to listeners

Scroll the figure sideways

A plugin declares a closed catalog and the host admits it. What crosses between two of them is a route id or a record contract, never a dependency: each one is built, versioned, and installed against the host alone.
The Call Goes Through the Hostroutes
A suite in one plugin calling a route the other plugin serves, with the host carrying the call and the reply.plugin aa suitehostroutingplugin ba routeeach one is built against the host alonereply dashed

Interaction 1

Routes Between Plugins

An instrument plugin publishes what it can do as routes, the way the synthetic testbench publishes its readiness behind a read-only status route. A step in another plugin's template reaches one through the host, which knows which sidecar registered that id, carries the request under its deadline, and returns the reply. The caller names a route id, never a crate.
Published Once, Heard by Allrecords
A watcher publishing a record, the host admitting and stamping it, and listeners in every plugin hearing it.watcherin plugin bhostadmits, stampslistenerin plugin alistenerin plugin clistenerin plugin done contract, one source stamp, every plugin

Interaction 2

Record Admission

The synthetic bench declares a listener for the record that says a unit came online, and hears it with no second plugin installed beside it, because admitting a record against its contract, stamping the plugin that published it, and forwarding it are all the host's job. Channels travel the same way: the mini sidecar declares its process-wide channel on the row type its sampler returns, and a template elsewhere names that type to have those rows captured beside its own.

Fig. 3 · Three Teams, One Toolchain

Building and Releasing a Plugin

A plugin is built the way any other project is built: created, developed, tested, and released from its own repository. What comes out is one versioned file, and the host takes it from there.

Three plugin repositories building into one hostThree independent repositories, each owned by a different team, run the same four commands: cargo dokime new, cargo dokime dev, cargo test, and cargo dokime build with the release flag. Each produces its own versioned bundle file, and all three bundles are installed into one Dokime host.THREE REPOSITORIESTHE SAME TOOLCHAINA VERSIONED BUNDLEONE APPLICATIONInstrument Pluginthe team that owns the benchSuite Pluginthe team that owns the proceduresReporting Pluginthe team that owns the dataPLUGIN TOOLCHAINcargo dokime newstartcargo dokime devruncargo testprovecargo dokime build --releaseshiprun in each repository, by each teaminstrument-2.3.0.dokimesuite-1.7.2.dokimereporting-0.9.4.dokimeDOKIME HOSTOne applicationEach bundle installedand authorized on itsown, by its own bytes.one catalog forevery tester

Scroll the figure sideways

Each lane ends in one file whose name, version, and description come from its Cargo package. The host reads that bundle’s frozen catalogs before a line of its author’s code runs.
One Package per Repositoryscope
A small repository holding one Cargo package and its tests, next to the single large tree it replaces.one large treeone packagethe driverand its testsnobody reads the left one to change the right one

Packaging

The Plugin Repository

A plugin is an ordinary Cargo package that depends on dokime and nothing exotic. Its own repository holds its source, its assets, and its tests, and copying the reference sidecar out of the product tree into a repository of its own is a supported way to start.
Every Plugin Has One Ownerteams
Three plugins, each paired with the one team that owns the thing it drives.instrumentthe bench ownerssuitethe procedure ownersreportingthe data ownersno shared file for two teams to argue over

Identity

Bundle Identity

Bundle identity follows Cargo: the package supplies the name, the version, and the description, and the files under assets travel at the same relative paths. There is no second authored manifest, so there is no second file for anyone else to edit.
Three Lines, No Crossingdevelopment
Three repositories advancing along their own lines at their own pace, with no branch shared between them.instrumentsuitereportingthree repositories, three histories, three paces

Toolchain

The Command Set

The same four commands run inside each repository, against whatever revision that team is on. Nothing in the toolchain asks the three lines to meet, and a build is refused whole rather than half-written: a compilation or an export that fails leaves the previous bundle exactly where it was.
Each Ships on Its Own Versionreleases
Three plugins at three different versions, each installed into the same host without asking anything of the others.instrument2.3.0suite1.7.2reporting0.9.4one hostunchangedupgrading one asks nothing of the others

Admission

Compatibility Checks

Before it compiles anything, the development command reports which host it selected, where it found it, and the CLI, host, and SDK versions, then checks their supported compatibility series. Installing goes further: the bundle is staged, its frozen catalogs are read without running a line of authored code, and its identity and digest are shown before anyone consents.

Authoring

Authoring a Step

An author declares a step, a criterion, a channel, and the parameters a template expands into cases. Each declaration states what that one thing is. The machinery that schedules it, streams it, stores it, and renders it is already written, and it is not written here.

  • +Scheduling, retries, pausing, resuming, and cancellation.
  • +Expanding parameters into the concrete cases a cycle will run.
  • +Storing measurements, evidence, and operator answers durably.
  • +Rendering the report, and making it open without a server.

Both figures are read from the repository’s main line when this page is built, between anchors in the text rather than at line numbers. If the source moves, the figure leaves rather than lies.

Fig. 4 · One Stepplugins/mini/src/suites/checks/pulse.rs
/// The first phase: say the run has begun.
///
/// The host advances its checklist on the step's id, which the engine
/// reports before it calls this. What the step itself does is emit the
/// record this template declared.
#[dokime::step(label = "Start")]
fn start(&mut self, ctx: &mut StepContext<'_>) -> Result<(), Error> {
    ctx.publish(RunStarted {});

    Ok(())
}

The attribute declares the phase; the body publishes the one thing this phase means. A tester sees that label move on a checklist, and a reader of the report sees the record it emitted.

Fig. 5 · One Measurement Channelplugins/mini/src/samplers/system.rs
/// One reading of this process and the machine under it.
#[dokime::stream(id = "mini-sidecar.system", window = 4096, label = "Mini Sidecar System",
    description = "Process and system CPU and memory observed by the mini sidecar.")]
pub(crate) struct SystemRow {
    process_cpu_percent: f64,
    process_memory_bytes: i64,
    system_cpu_percent: f64,
    system_memory_used_bytes: i64,
}

A field’s column type is resolved from its declared type, so a number column is a number column because the compiler said so. Declaring the row is the whole of declaring the channel: there is no second place to keep in agreement.

Design Intent

The Division of Labour

Nobody outside your lab knows your instruments, and a platform that pretended to would be wrong in a different way for every team. So it does not pretend. It gives you somewhere exact to put that knowledge, once.

What the Platform Carriesdokime
The five parts the platform carries, sitting under the line a test system is built on.the line your test system stands onhostdesktop appplugin sdkrecordsreportsbuilt once, for every lab, by somebody who is not you

Below the Line

What Dokime Gives You

The parts that are the same in every lab, built once and kept working by somebody who is not you.

The Host
Scheduling, execution, routing, coordination, and the record.
The Desktop App
The five screens a tester uses, and the reports they export.
The Plugin SDK
The declarations, the toolchain, and the bundle format.
The Records
Durable, contracted, and traceable without anyone typing them.
The Reports
Self-contained, offline, and generated by the run itself.
What Stays Yoursyour plugins
The five things only a lab knows, sitting above the line the platform draws.yours, and rightly soyourinstrumentsyourtest stagesyourrequirementsyourdata platformyourlab hardwaredokime stops exactly here, on purpose

Above the Line

What You Bring

The parts that are different in every lab, which stay where the knowledge about them already is.

The Plugins That Know Your Instruments
Your supplies, loads, chambers, analyzers, and the one fixture nobody else has.
Your Test Stages
What design validation means here, and what has to be true before a unit moves on.
Your Requirement Tracker
Wherever the requirements already live. A plugin reaches it; the platform does not replace it.
Your Data Platform
Where results go afterwards, and in whose schema. The run is a producer, not an owner.
Your Lab Hardware
The bench, the racks, the wiring, and the years of knowing what breaks on them.

Dokime is the substrate, and the test hub your organization actually runs is the thing you build on top of it.

That hub carries your catalog, your stages, your instruments, and your name. What it does not have to carry is a scheduler, a record store, a report renderer, or a plugin boundary, because those arrive underneath it and stay open source. Write one plugin for the instrument your team already understands, and everybody else gets to run it by pressing a button.

MIT OR Apache-2.0

Contributing

All of Dokime is public: the contracts, the SDK, the runtime, the server, the desktop shell, and the reference plugins that this page quotes from.

Bug reports, focused fixes, documentation improvements, and small plugin examples are welcome. The contributing guide carries the development setup, the validation commands, and what a merge request is expected to describe.

License
MIT OR Apache-2.0, at your option
Platforms
Windows and Linux
Maturity
Pre-1.0. Pin the exact revision you test against.

Known Limits

The core workflow is usable, but interfaces and plugin contracts may still change between revisions, which is why a revision is worth pinning. Continuous integration covers the Linux container checks; installation and hardware behaviour on Windows still want validation on real machines.

Browse the SourceRead the DocumentationRead the Contributing Guide