# With Plugs Example URL: /examples/with-plugs The upstream with_plugs.py example — write one phase against a plug placeholder, then generate several phases with phase.with_plugs() and with_args(), each with its own name and measurement. One phase, three instances. When the same check must run against several interfaces (four NICs, three power rails, two radios), write the phase once against a **placeholder** plug and stamp out concrete phases with `with_plugs()`. Based on `examples/with_plugs.py`. The record contains three phases — `Ping-google.com-2`, `Ping-8.8.8.8-2`, `Ping-8.8.4.4-2` — each with its own `total_time__2` and `retcode` measurements. On Windows replace `-c` with `-n`. Every `BasePlug` subclass has a `.placeholder` attribute. Decorating with a placeholder makes the phase abstract: it cannot run until `with_plugs()` substitutes a concrete subclass. Returns a copy of the phase with the placeholder replaced. The substitute must be a subclass of the placeholder's class. Fills extra positional parameters of the phase function and any `{count}`-style templates in the phase name, measurement names and validator arguments. Dynamic naming → Templates can reach into plug attributes, so each generated phase and measurement is uniquely named in the record. A templated validator argument. `type=str` tells the validator how to cast the substituted string. Per-channel tests: `with_plugs(rail=Rail3V3)`, `with_plugs(rail=Rail5V)`, ... over one `measure_rail` phase. The same DUT test across several fixtures or instruments, selecting the plug subclass from configuration. Table-driven test plans: build the `phases` list from a CSV of (channel, limit) rows. For plug instances that differ only by constructor arguments (two multimeters on two COM ports), `configuration.bind_init_args` is the lighter tool — see Multiple plug configuration.