Plug into Worker SDK
If you write function blocks and need a real Netlab topology to test them against, the Remote Lab side is two lines of setup. The patterns live in the Worker SDK testing guide — this page hands you off cleanly.
Wrong page?
Just want to run a pytest test against a real topology, not via Worker SDK? The plain pytest path is shorter. Driving from a non-Python stack? See Drive from cURL.
What you need
- A Worker SDK installation in your project (see install block below if you don’t have it yet).
- A reachable Remote Lab Manager — see Run locally if you don’t have one yet.
pytestalready in your test environment.
If you still need the Worker SDK itself:
Two setup steps
1. Install the Remote Lab client alongside the Worker SDK:
The package ships both the pytest plugin (remote_lab_fixture) and the HTTP client (RemoteLabClient); pytest discovers the plugin automatically.
2. Point the client at your Remote Lab Manager:
That’s the Remote Lab side. From here on, the Worker SDK owns the testing patterns.
Where to go next
The Worker SDK’s Remote lab testing guide covers the function-block-test patterns:
- Where to declare
remote_lab_fixturein the worker test layout - Fixture-rank ordering across multiple worker test modules
- Multi-vendor patterns when a function block targets several NOSes
- The
reuse_lab=Trueswitch that collapses queue contention across a function-block test suite
Read it next.
See also
- With Worker SDK — the Remote-Lab-side notes for Worker SDK consumers (which topology kinds, multi-vendor recipes, where fixtures go in the worker test layout).
- Pytest fixtures — the public API the Worker SDK imports.
- Worker SDK → Function blocks — the unit of automation work whose tests this fixture serves.
- Neops ecosystem — how Remote Lab fits with the rest of the platform.