x01dc
68a56607b8
Two bugs found by comparing omny's RT-flyer code against flomni's (per
Mirko, since flomni/lamni's fermat scans already work fine in sim).
1. Root cause of the reported scan hang (tomo_scan_projection() starts a
scan but the progress bar freezes at 0% forever, no error):
RtOMNYFlyer.read_positions_from_sampler() called self.get_scan_status()
instead of self.controller.get_scan_status(). get_scan_status() only
exists on RtOMNYController, never on RtOMNYFlyer -- so this line raised
an AttributeError inside the background thread complete() spawns for
readout. An uncaught exception in a thread target doesn't propagate;
the thread just dies silently, before ever calling status.set_finished().
scan_core()'s `while not status.done` loop then spins forever, and since
the thread died before ever updating progress, the bar stays at 0%.
Confirmed correct in both RtFlomniFlyer's and RtLamniFlyer's equivalents
already; fixed to match.
2. RtOMNYSetpointSignal._socket_set() never had the laser-tracker-signal-
strength guard RtFlomniSetpointSignal._socket_set() got in commit
68320e1 ("check tracker signal before rt move, which is otherwise stuck
forever") -- a real-hardware failure mode (a move issued with a weak
interferometer signal never converges). OMNY has its own duplicate
setpoint-signal class, so the fix never propagated. Ported using OMNY's
own existing laser_tracker_check_and_wait_for_signalstrength() (a more
capable, retrying/auto-readjusting check) rather than flomni's
single-shot version, which OMNY doesn't have. Lower confidence this one
is the actual cause of the reported *simulated* hang specifically --
the sim doesn't model signal-dependent convergence -- but it's a real,
confirmed gap worth closing for real-hardware safety regardless.
4 new regression tests in tests/tests_devices/test_rt_omny.py, including
one that directly confirms the fake stand-in used for bug #1's test would
have caught the original bug (raises AttributeError the same way the real
class would).
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.