Back to resources
Testing
CI

From CLI Prototype to pip install embeddedci

The moment BenchPod stopped being a tool you drove by hand and became a pytest fixture: putting the SDK on PyPI, and the five-step loop it was built to unlock.

Edward Viaene · June 9, 2026 · 2 min read

For a while, using a BenchPod meant importing it out of a local checkout: fine for developing the SDK itself, useless for anyone who just wanted to write a hardware test. That changed with one small, unglamorous milestone: embeddedci landed on PyPI. pip install embeddedci, then pytest, and the hardware test suite runs like any other.

It's a small change with an outsized effect, because it's the piece that turns "a board on a bench with a debug probe" into "a fixture in a test file." The whole point of packaging it was to make this the boring, ordinary end-to-end loop:

  1. Attach a BenchPod to the target device.
  2. Point it at a network: configure Wi-Fi or Ethernet and find the device from the CLI.
  3. pip install embeddedci.
  4. pytest.
  5. Wire that same test into CI, either a local runner sitting next to the hardware, or embeddedci.com proxying the request to a pod anywhere else.

Steps 1 and 2 are a one-time bench setup. Steps 3 through 5 are what most projects actually repeat, and packaging the SDK is what makes step 3 a single, ordinary pip install instead of a checkout of someone's firmware repo.

Python test code exercising hardware through the embeddedci SDK
Python test code exercising hardware through the embeddedci SDK

Why this was worth doing before the hardware was "done"

At the point this shipped, the board itself was still mid-generation: the switch from the v1 RP2350B design to the STM32H563-based v2 hadn't happened yet. Packaging the Python side first, ahead of the hardware settling, was deliberate: the SDK and the pytest integration are the surface every test author actually touches, and they're the part that most needed to stop feeling like a research prototype. A board revision changes wiring and part numbers; it shouldn't change how someone writes def test_boots(benchpod): ....

That decoupling is also what let later work, the GitHub Actions cloud path and the on-pod CMSIS-DAP probe, bolt onto the same benchpod fixture without changing the shape of a test. If you want the fast path from a fresh pip install to a green hardware test, that's Your First HIL Test in 15 Minutes; the fixture and CLI reference lives in the pytest framework docs.