Tests Build Worker module
This module owns a distinct part of the HSLG implementation.
Boundary and failure-case tests
The build-worker tests exercise the narrow security boundary between WordPress administration and the private Ubuntu compiler. queue-test.php uses simple WordPress test doubles to assert that unauthorised visitors do not queue builds, that a valid source checksum creates one job, and that repeated administrative requests do not schedule duplicate jobs, and that a failed build is retryable on the next plugin release without claiming success. This test does not pretend to own a real WordPress database or a production dashboard.
test_worker.py imports the actual restricted Python worker and checks the source ZIP that will ship with the plugin. It verifies that the archive is protected by an ABSPATH PHP guard, contains the genuine mobile source and compilation scripts, and excludes WordPress configuration, signing keys and demonstration-only code. Crafted ZIP entries with parent-directory traversal and excessive unpacked bytes must be rejected before they can write outside the build workspace.
Debug-artifact evidence
A deliberate failed-build fixture exercises debug archive creation and verifies that the full compiler log and diagnostic JSON are recoverable from the private ZIP. This is a critical contract because a failure without a log would force the operator into repeated manual SSH diagnosis. Other tests cover the release manifest, route authorisation and shell isolation in tools/governance/check_build_worker.py.
Limits and maintainer obligations
These are local tests, not proof that cron, WP-CLI, PHP-FPM permissions or Gradle work on a freshly upgraded Virtualmin site. Run a real HSLG release upload, inspect the AJAX modal, download the full debug ZIP and test the native APK on a physical phone before closing the operational gate. If a source path, manifest format or download endpoint changes, update both the PHP queue test and the Python worker tests in the same release.
Source files in this module
Maintenance and evidence
Check all affected file references and the matching human-readable user/architecture page when source changes. Run the module’s contract or governance checks; staging, payment and native hardware tests remain independent of source inventory coverage.