Mocks have already been used to test jpackage. Mocks simulate the subset of functionality provided by native tools that jpackage requires. This simplifies testing by allowing the environment where jpackage runs to be simulated instead of adjusting tests to the specifics of the real environment.

E.g.: some macOS signing tests can be executed without deploying the full signing test environment. Some RPM/DEB-specific code can be tested on any Linux distro, even those that don't support either packaging.

A few changes are required to enhance the scope of jpackage's functionality for testing with mocks:

 - Decouple jpackage implementation and test helpers from the current OS: replace OperatingSystem.current() calls with parameters and/or fields of type jdk.internal.util.OperatingSystem where feasible.

 - Support running only the configuration phase in jpackage without running the final packaging phase. This would enable full testing of the first phase, which parses command-line options and builds a model, without running external packaging tools. External packaging tools are also used at this phase, but their functionality can be easily mocked. E.g.: it is trivial to mock "dpkg --print-architecture" command, making it possible to test a model that jpackage creates for DEB packaging. Yet mocking the entire functionality of the "dpkg" command is unfeasible.