Testing
Network automation mistakes are expensive — a bad config push can take down production links. Testing your function blocks before deployment is not optional; it is the single most important step in your development workflow.
The SDK provides three levels of testing:
| Level | What it tests | Speed | Devices needed |
|---|---|---|---|
| Standalone | Logic, parameters, results | Fast | None |
@fb_test_case |
Full execution lifecycle with blocking detection | Fast | None (mock context) |
@fb_test_case_with_lab |
End-to-end against real devices | Slow | Remote lab |
In This Section
| Guide | What you’ll learn |
|---|---|
| Test Suite Setup | pytest configuration, asyncio mode, conftest patterns |
| Testing Function Blocks | Standalone tests, @fb_test_case, mocking connections |
| Remote Lab Testing | @fb_test_case_with_lab, lab fixtures, topology provisioning |
| Testing Plugins and Proxies | Plugin tests, registry isolation, capability verification |
| Debugging | VSCode setup, common errors, blocking detector, logging |
Quick start
For a minimal first test, see Testing Your Function Block in the Getting Started guide.
The Remote Lab itself lives at neops-remote-lab
The SDK imports remote_lab_fixture as a stable public API; the lab’s
own docs cover architecture, queue semantics, topology format, vendor
setup, and deployment.
Standing up your own? Two entry points:
- Run locally — install on
localhost:8000for offline dev (~10 min). - Pick a deployment — decision tree for shared VM / multi-tenant / CI runners.