menzelandClaude Opus 4.8
e71f2df284
Expose each SCS axis as its own top-level BEC motor sharing a singleton SmargopoloController per host:port, plus a thin `dev.smargon` coordinator for whole-goniometer ops. Replaces the single-device-with-axis-subcomponents design. Why: BEC's motor UX (dev.wm, umv, limits, GUI motor widgets) is keyed on top-level devices. With sub-components, dev.wm showed `readback N/A` (it looks up a key equal to the device name) and `limits [0,0]` (the client reads limits from the root device's low/high_limit_travel signals). General, not a sim artifact. - controller.py: SmargopoloController(OphydObject), singleton per (host,port,sim); owns transport + lock + mode; referencing / move_scs / nudge / q1..q6 diagnostics. Reachable as dev.<axis>.controller.<op>() (USER_ACCESS). - positioner.py: SmargopoloMotor(Device, PositionerBase) -- top-level per-axis motor. scs_axis field binds the (user-chosen) BEC name to the fixed SCS axis. Exposes low/high_limit_travel signals and aliases readback to the device name, so dev.wm shows real per-axis readback + limits (low==high => unbounded). egu auto from axis. - smargon.py: SmarGon(PSIDeviceBase) reduced to a thin coordinator delegating to the shared controller; keeps read-only mode/rosout signals. - YAML: smargon.yaml + smargon_sim_session.yaml rewritten to per-axis entries (sgx/sgy/sgz/sgchi/sgphi[/sgomega]) + coordinator. Names user-configurable; SCS binding explicit via scs_axis. - transport/ layer + fake unchanged. Tests rewritten: 29 pass vs FakeTransport (singleton reset fixture; covers sharing, wm readback aliasing, limits, fault paths). Still DRAFT / untested against hardware. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Getting Started with Testing using pytest
BEC is using the pytest framework. It can be installed via
pip install pytest
in your python environment.
We note that pytest is part of the optional-dependencies [dev] of the plugin package.
Introduction
Tests in this package should be stored in the tests directory.
We suggest to sort tests of different submodules, i.e. scans or devices in the respective folder structure, and to folow a naming convention of <test_module_name.py>.
It is mandatory for test files to begin with test_ for pytest to discover them.
To run all tests, navigate to the directory of the plugin from the command line, and run the command
pytest -v --random-order ./tests
Note, the python environment needs to be active.
The additional arg -v allows pytest to run in verbose mode which provides more detailed information about the tests being run.
The argument --random-order instructs pytest to run the tests in random order, which is the default in the CI pipelines.
Test examples
Writing tests can be quite specific for the given function. We recommend writing tests as isolated as possible, i.e. try to test single functions instead of full classes. A very useful class to enable isolated testing is MagicMock. In addition, we also recommend to take a look at the How-to guides from pytest.