Skip to main content

The plug-in framework

Test Services is not a fixed set of tests. It is a core framework that hosts tests contributed by plug-ins, so the verification it offers can grow without changing the application itself. The framework itself is not specific to OpenLab CDS. Its built-in tests verify the underlying OpenLab platform. OpenLab CDS support arrives as a plug-in on top. As a result, the same framework can host verification for other Agilent applications built on it. Understanding this design explains why the tests on a machine depend on what is installed, and why a single faulty plug-in can leave the test list empty. For where each test actually runs, see Available tests.

A framework that hosts tests​

The framework provides everything common to every test: the home page that lists tests, the way a run is executed step by step, result reporting, scheduling, and notifications. The tests themselves are supplied by plug-ins. The framework discovers the installed plug-ins at startup and presents their tests in one combined list, so from your point of view they look like a single product.

Because tests are contributed rather than built in, the list on a machine reflects what is installed there. If a plug-in is not installed, its tests simply do not appear. If no plug-ins were installed at all, the test list would be empty. A test is shown as enabled when its prerequisites are met and disabled, with the reason, when they are not.

The plug-ins that contribute tests​

Some plug-ins are installed automatically with the Test Services core, and others are installed separately on top of it:

  • Installed with the core. The Security Test, the Storage System Test, the Software Installation Verification Test, and the System Report are part of the standard installation. These framework tests verify the shared OpenLab platform (Shared Services security, the storage system, software-install integrity, and the system) rather than OpenLab CDS itself.
  • Installed separately. The OpenLab CDS plug-in adds the Workflow Test and the Connectivity Test. It requires the Test Services framework to be present first and is installed where acquisition and connectivity verification are needed. To add it, see Install a Test Services plug-in.

For what each test verifies, see the System Report and the other test pages.

Versions must match​

A plug-in and the framework that hosts it must be the same version. The framework loads its plug-ins as a set, so a plug-in left behind at an older version after an upgrade cannot be loaded selectively. When versions do not match, Test Services cannot load the tests and reports a version-mismatch message rather than showing a partial list. Keeping the framework and its plug-ins upgraded together avoids this.

Why all tests load together​

The framework loads all installed plug-ins as a single unit. This keeps the combined test list consistent, but it has a trade-off. If one plug-in fails to load, for example because a file it depends on is missing, none of the tests load and the list is empty. An empty test list after login is therefore usually a plug-in loading problem rather than a sign of missing licenses or permissions.

note

If the test list is empty after you log in, a plug-in failed to load or a plug-in version does not match the framework. This is an administrator issue; have an administrator check the installation rather than re-running the login.

See also​