Two instruments, one test, one answer¶

Many tests need more than one instrument, and each usually comes with its own software, so someone puts the answers together by hand after the run. Here one test checks two instruments on different wires and returns one answer for the whole bench. The last post swapped one instrument for another; this one keeps both.

Why two instruments mean two answers¶

A bench that needs a second instrument usually gets a second tool with it. Each instrument has its own software, its own log, and its own way of saying what it saw. The run leaves one record per instrument, and after the run someone lines them up: this reading at this step, that reading at the same moment, so the device did what it should.

That is a reasonable way to get a bench working, and in many teams it works. But the joined answer is a person's judgment, not a record. A developer who reads it has to trust the person who put it together, and when the person is busy, the answer waits.

Each instrument is one more role¶

In Knilb, a plan declares named roles, and each role has a contract: the OpenAPI spec of the interface it answers on. Every step targets a role, never a particular machine. So the plan, not a person, decides which instrument each step checks.

A deployment binds a participant to each role. On this bench there are three roles: one for the device under test and one for each instrument. Adding an instrument adds a role and a binding, and the steps that use it. The testbed model explains how roles keep the test apart from the bench.

Two instruments on one thermostat¶

The bench is the one from the bench story. A Wi-Fi thermostat is the device under test. An off-the-shelf networked I/O monitor watches its fan wire, in a role called fan_monitor, and a small single-board computer watches its heat and cool wires, in a role called relay_monitor.

The test turns the fan on, and the monitor confirms the fan wire closed. It then calls for heat, and the computer confirms the heat wire closed while the cool wire stayed open. At the end, the computer has counted exactly two changes on the heat wire, one clean heat cycle, and the run passes.

What this bench shows is specific: two instruments, each in its own role, watching different wires of the same device, in one run.

One result for the whole bench¶

The run ends with one verdict. The steps from all three devices sit in one list, in the order they ran, so the fan wire, the heat wire, and the cool wire are checked against the same calls to the thermostat.

Each result freezes the deployment as it was cast, so it keeps the address of the device behind every role. A developer reads the record, not someone's summary of two records, and it says the same thing when someone reopens it later. Each wire in it was observed, not assumed from what the thermostat reported.

What one answer is good for¶

When a bench needs another instrument, it gets another role, not another report to reconcile. The answer a developer gets is the run's own, so it can be trusted without asking who joined it, and nobody has to line up logs before the next build can move.

The bench story shows the full bench, with the video in context beside the benches it extends. The next post builds the instrument.