x01dcandClaude Sonnet 5
49ade7ce98
OMNYGuiTools still used pre-modernization code: a gui_window handle that was never actually populated (self.gui.windows["main"].widget always raised/returned None), the old two-level add_dock().add_widget() API, and bare `if self.figN is None` checks instead of an _is_deleted()-aware guard. omnygui_show_progress() crashed with AttributeError as soon as it was exercised live. Ported OMNYGuiTools onto flomni's current single-level .new() pattern: split __init__()/set_client(), a window-reuse check keyed on self.gui.windows, _omnygui_is_missing() for dock-reuse (verbatim port of flomni's _is_deleted()-based guard), the current RingProgressBar API for omnygui_show_progress(), and new omnygui_show_xeyealign()/ omnygui_show_xeyealign_fittab()/omnygui_show_cameras() methods. cam_xeye is not part of omny's device config (unlike flomni's), so the xeyealign live-view toggle is guarded with an existence check instead of copied unconditionally. omnygui_show_cameras() adds a hard-stop console targeting otransy, the closest omny analog to flomni's ftransy. Also fixes two independently-broken call sites in x_ray_eye_align.py (self.lamni.lamnigui_show_xeyealign[_fittab]() -> the omny-side method names actually defined on OMNYGuiTools -- self.lamni is really the OMNY instance) that were raising AttributeError before the GUI code was even reached. The rest of that file's LamNI-derived content is left alone; a full rewrite is tracked separately. omny.py's __init__ now calls OMNYGuiTools.__init__(self) + set_client(), matching the split-constructor pattern instead of the old single-call OMNYGuiTools.__init__(self, self.client). Deliberately deferred: flomni's ETA/heartbeat progress fields (tomo_start_time, heartbeat, estimated_remaining_time, etc.) are not ported -- omny's self.progress dict only has 7 basic fields. Noted in omny/AI_docs/OPEN_ISSUES.md so it isn't forgotten; not a crash risk since omny_webpage_generator.py already reads these defensively. 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.