x01dcandClaude Sonnet 5
f9a1f4a7d2
Live-testing findings from Mirko's own session, four real bugs: - tomo_parameters() now warns when the current fovx/fovy/tomo_shellstep would yield fewer than OmnyFermatScan.MIN_POSITIONS (20) Fermat scan points, matching Flomni.tomo_parameters()'s identical warning -- the scan server already aborted (ScanAbortion) on too few points, but nothing told the user ahead of time. Needed converting OmnyFermatScan.get_omny_fermat_spiral_pos() to a @staticmethod (was an instance method reading self.cenx/ceny/zshift) so it's callable from tomo_parameters() without a full scan instance, matching flomni's already-static version. Also promoted the hardcoded "20" in prepare_scan()'s abort check to a MIN_POSITIONS class constant. - OMNY.tomo_scan() didn't accept interactive=, so every tomo_queue_execute() run (which always calls tomo_scan(interactive=False) for unattended queued runs) failed immediately with TypeError. Added the parameter, accepted but unused, matching flomni's own docstring reasoning (no fine-alignment gate on either setup). - write_to_scilog()/write_pdf_report() used the old bec.logbook API with no "is scilog configured" check, so a session without scilog credentials hung indefinitely instead of failing fast (confirmed live: 29+ minutes). Migrated both to bec.messaging.scilog, gated on _enabled, matching flomni's actual current mechanism. - Stale ~/Data10/specES1/ paths (predating the current ~/data/raw/ deployment layout) crashed _write_tomo_scan_number() with FileNotFoundError on a fresh session. Fixed that plus write_pdf_report()'s PDF target and tomo_reconstruct()'s default base_path, all three sharing the same stale root -- now also explicitly create their target directory first, since flomni's own equivalents assume it already exists. 16 new tests across test_omny_fermat_scan.py, test_omny_tomo_angles.py, and test_omny_tomo_scan.py. Full suite: 725 passed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QLrD7sVYGLAzsQjLVJpCgt
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.