Where does the manual effort sit today?¶
For most teams building connected products, not in the unit tests, the API tests, or the build. Those run on every commit. It sits at the end, where the whole product gets checked by hand: set up the bench, run the plan, watch the LEDs, check the app, restart, try again. If that is your week too, you have probably run into all three of these.
-
No tool runs the whole system
CI, source control, and test management each cover their part. Exercising the whole product together is still a person at a bench.
-
Real hardware, not emulation
The failures that reach the field depend on electrical, timing, and physical behavior. Trusting a system-level result means observing the real device with real test equipment.
-
Field failures are slow to reproduce
A gap that was visible in development turns up in the field, where recreating the conditions takes weeks instead of minutes.
What would it take to stop doing it by hand?¶
With Knilb, the whole product is validated as one system. You describe each part by its API, the cloud service, the gateway, the device, and the test equipment on the bench, and write one plan against all of them in the web app. A small command-line tool on a machine in your lab runs that plan against the real parts, or against mocks before the hardware exists, and reports every step back. What comes out is a single pass or fail for the whole product, with a record of exactly what ran, so a failure is reproduced from facts rather than from memory.
The tutorial on the documentation site takes you from an empty account to a green result in about twenty minutes, with a mocked thermostat. Everything you build there runs unchanged against real hardware later. Unbinding the mock is the whole difference.
Three things to check for yourself along the way: a mocked role never reaches the real participant, every step records which layer answered it, and every result freezes exactly what ran.
Unbind the mock and the same plan runs against the device on the bench. Test equipment takes part like any other participant: an instrument that exposes its own API contract is cast into a role and does the translation between the wire and the API, so a relay closing or a line changing state is observed and asserted on, not inferred from what the software reports.
Ask, and we will show it running live. How physical interfaces are reached has the detail.
Work with us¶
Knilb works with a small number of design partners: teams shipping a connected product on a real cadence, past prototype, with hardware, firmware, cloud, and physical interfaces all still changing, and no working harness for the whole system yet. A design partner gets full product access, hands-on setup, and a direct line for support, and runs Knilb against their own hardware. If that sounds like your team, tell us what you are building.