Dokime, Tests with a Memory
The Usual Test Bench
Test work tends to begin sensibly. There is a procedure, a script, and perhaps a spreadsheet with the important numbers. Then the procedure grows branches, the script acquires three special modes, screenshots multiply, and nobody is entirely certain which file belongs to the run that failed on Tuesday.
I built Dokime to give that mess a proper shape without pretending that tests are fully automatic. Real test benches have instruments, operators, odd pauses, and hardware that occasionally needs a firm look.
From a Suite to Evidence
In Dokime, authored suites and templates become cycles of concrete executions. A run can stream telemetry into live plots, publish typed events, pause for an operator prompt, and attach files as artifacts. When the cycle is done, those pieces become a self-contained report instead of a scavenger hunt through folders.
The runtime is written in Rust. There is a Tauri desktop application for the operator, a command-line interface for deterministic runs, a Python bridge for test authoring, a REST surface for the GUI, and an MCP interface for tool clients. Plugins contribute test catalogues, execution adapters, telemetry samplers, actions, settings, and branding. Keel supplies the lower-level runtime machinery so Dokime can concentrate on testing rather than rebuilding journals and supervised jobs again.
Automation Without Theatre
The point is not to automate every click. Some tests need a person to move a fixture, inspect a beam, or decide that a noise is probably not meant to be there. Dokime makes those moments explicit and records the answer beside the machine data.
The project is still pre-release and its boundaries are moving as the runtime settles. The useful behaviour is already clear, though: define the work once, run it repeatably, and keep enough evidence that the report can answer awkward questions later. A test system should remember more than the engineer who ran it at six in the evening.