menzelandClaude Opus 5
7ecbf1147d
Three hardware results on 2026-08-18, three different consequences. Presets work -- the last protocol guess is now measured -------------------------------------------------------- `control.cgi?p=<id>` recalls a preset. The inference that control.cgi writes the same names info.cgi reports held, and with it the transport has no unverified guesses left. R3 marked resolved; the docstring records that recall runs at the preset's own stored speeds (300 deg/s on p.1) and moves every axis at once. Jog does nothing -- so it now says so -------------------------------------- Writing c.1.<axis>.speed on its own does not start continuous motion; the field is a setting the *next move* consumes. The camera accepted the write and did nothing -- the same silent acceptance that hid the broken stop(). Keeping a no-op that reports success would repeat exactly the mistake that cost us the stop() bug, so jog() raises with an explanation instead, and jog_pan/jog_tilt come out of USER_ACCESS: that list is the discoverable API and must not advertise a capability the hardware lacks. The methods stay so the failure explains itself rather than surfacing as AttributeError, and the message points at the two real options -- repeated move_absolute(), or harvesting the continuous-move command from the camera's own web UI. Focus was "hard to tell" -- so the test was wrong, not the answer ----------------------------------------------------------------- check_focus_mode sampled the focus readback for drift and called that the difference between manual and auto. On hardware that is inconclusive: autofocus on a static, well-lit scene barely hunts, so "not drifting" proves nothing either way. A weak test that yields a shrug is worse than no test, because it looks like coverage. Replaced with a functional one: set manual, command a focus move, and check the value both reaches the target and stays there. In auto the camera owns the focus loop and will not leave it there, so this actually discriminates -- and the image visibly defocuses, which is a second, human-readable check. The three outcomes (reached-and-held / reached-then-slid / never-reached) map to different causes and say which. Tests: 124. Co-Authored-By: Claude Opus 5 (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.