Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Running Hardware Tests

Unit tests allow us to check for code coverage and ensure that functions in the source code are operating as expected. When running tests to determine code coverage, the test suite must be ran against a single snapshot of the source code, ideally from a single commit hash of the repo to github. Before running tests, ensure you have the correct version of the source code to be tested.

As not all functionality can be replicated in a simulated microscope, there are multiple flavors of test functions that must be ran before new versions of the codebase can be formally released. These fall generally into the following categories:

  • Detached: tests that can run without autoscript installed.
  • Simulated: tests that can be run in a virtualized microscope requiring an offline autoscript license. Specific approved offline machine names are listed in the offline_machines attribute in the Constants module.
  • Hardware: tests that require a physical microscope. Specific approved microscope machine names are listed in the microscope_machines attribute in the Constants module.
  • Laser Hardware: tests that require a physical microscope with femtosecond laser module. Machine must be a member of the microscope_machines attribute in the Constants module and pass a laser hardware check to run these tests.

note

To have your specific machine added to the approved lists for running test suites, a source code modification of the Constants module will be required. This can be done locally after normal installation of pytribeam. Please contact the developer team for more information if you would like your machine name to be included in future releases.

How to run test suite on a physical microscope

caution

DO NOT run hardware tests if you are unfamiliar with the process. Contact the development team for more information before proceeding

Hardware tests inlcude movement of the stage as well as insertion of various detectors. As such, the microscope must first be prepared in order to safely run all tests.

Prepare the microscope for hardware tests

important

Before readying the microscope, ensure you have installed the current version of the software you would like to test. Installation instructions can be found here.

To ready the microscope for the test suite, do the following:

  • Remove any sample and sample holder from the chamber
  • Pump the chamber down to normal operating pressures to enable the electron beam and ion beam to operate
  • Disable CBS stage restrictions (available on non-Windows 7 machines)
    • check the "No stage tilt restrictions" box
  • Turn on electron beam, unblank the beam, set working distance to 15 mm, and link Z (need not be in focus)
  • Retract all insertable devices (EBSD/EDS detectors, CBS/ABS detectors, etc.)

Additional preparations for laser systems:

Laser systems require several more steps to run the more comprehensive test suite:

  • Open the laser GUI app from ThermoFisher and disable the laser interlock (turn the key on the laser so the laser can fire). The laser will fire briefly during tests but will not be focused into the chamber. Keep the laser app open to enable API commands
  • Unlock the objective in the laser app and make sure you can read a physical position
    • The laser injection port (LIP) may need to be homed for this, which will require a chamber vent
  • Start the laser (ensure it is not in "Standby" mode)
  • Zero-out "Beam Centering" and "Beam Shift"
  • In XTUI, ensure the spin mill sample holder is selected
  • Open EBSD/EDS software
    • Oxford systems only: enable proximity sensor and override alerts
  • Optional verification steps:
    • Open pytribeam GUI and run "test connections" to ensure no "Error" states

Execute the test suite

From the pytribeam repo directory (folder containing folders like src, docs, and tests) you should see a file entitled local_ci.py, with the most recently released version found here.

Run the local_ci.py file from a terminal window, ideally in an application like VSCode. This will generate the directories logs, badges, and coverage_reports.

To update coverage reports for future releases, please share the logs and coverage_reports directories generated by running local_ci.py with the development team.