menzelandClaude Opus 5
653351fc15
The JungfrauJoch broker reports packet loss during data collection as a plain error, which fails the scan. Since 2026-09-03 that error has been suppressed on the beamline by an uncommitted edit, through a hardcoded flag on the Eiger base class: it applied to every Eiger at once, it could be reached neither from the client nor from deviceConfig, and it left nothing in the log. The tolerance is now a real parameter, raise_on_missing_packets: - named in Eiger, Eiger9M and Eiger1_5M, so that a deviceConfig key actually reaches the device. bec_server intersects config keys with the named parameters of the class, so a flag reachable only through **kwargs is silently dropped -- the same trap as readout_time (f450f29) and prefix (10be2b5). A test pins the signatures. - exposed through USER_ACCESS as get_/set_raise_on_missing_packets, so a beamtime can change its mind without a redeployment. Like every runtime value it is shared between clients and does not survive a server restart; deviceConfig is what makes a choice stick. - counted, and logged at warning level whenever an error is let through, so that "which scans were affected?" has an answer. get_missing_packet_events() returns the count. What is tolerated is narrower than it looks: the frame-count check below still raises when statistics.images_collected falls short of the trigger count. Only "the broker flagged packet loss but delivered the expected number of images" gets through, and a test pins that a short acquisition still fails. The default stays False, i.e. tolerate, so the running beamtime is unaffected. It should become True once the 9M's packet loss is understood, with raise_on_missing_packets: false in that detector's deviceConfig if it still needs it. That is one constant to change, RAISE_ON_MISSING_PACKETS. The wording of the broker message is the only handle available, as there is no error code for it. If JungfrauJoch rephrases it the match stops working and the error raises again, which is the safe direction to fail in. test_eiger_on_complete_error_message was skipped as failing "because the error should be skipped for now due to HW issues". With the tolerance scoped to the missing-packet message it passes again, and is no longer skipped. 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.