2
0
mirror of https://github.com/xcat2/xcat-core.git synced 2026-09-05 12:37:54 +00:00
Files
xcat-core/xCAT-test/unit
Daniel Hilst 0925e2b599 test(makentp): the suite really disabled timesyncd on the host running it
Hoisting the systemd-timesyncd stop/disable above the ntpd hand-off moved it
inside the window makentp_ntp_deps.t extracts as $select, and that harness
stubbed only logger and check_executes. So the extracted region called the real
systemctl -- and the unit suite runs as root in CI. Probed with a recording
systemctl first on PATH, `prove makentp_ntp_deps.t` made 12 real invocations,
stop and disable for each of the six selection cases; on the Ubuntu review MN a
stand-in timesyncd unit went from enabled/active to disabled/inactive while the
suite reported PASS.

That is the "never let a test escape its scratch tree" rule, and it failed
silently: the assertions passed either way, so nothing said the host had been
changed.

Shadow every command the region can reach, not only the ones it reached when
this was written -- the region moves. Bash resolves functions ahead of $PATH,
so these win without touching PATH.

The stubs use echo rather than printf '...': the harness runs `bash -c '...'`,
so a single quote inside the prelude closes that string early. The existing
logger stub gets away with it; three more did not, and the ntpd selection cases
failed until they were rewritten.

Verified after: zero real systemctl invocations from the whole unit suite under
the same probe, and 18/18 still pass.

Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
2026-09-01 21:33:36 -03:00
..

xCAT-test/unit

Unit tests. These run against the source tree only -- no xCAT installation, no running daemons, no management node.

They are executed on every pull request by the xcat_test GitHub Actions workflow, which calls run_unit_tests() in github_action_xcat_test.pl:

prove -r xCAT-test/unit

You can run exactly the same thing from a clean checkout:

cd <xcat-core checkout>
prove -r xCAT-test/unit

What belongs here

A test belongs in unit/ when everything it needs is in the checkout: plugin and library sources, kickstart/preseed/subiquity templates, postscripts, packaging metadata. Such a test asserts on rendered output or module logic and reaches the repository root through FindBin:

use FindBin;
use lib "$FindBin::Bin/../../perl-xCAT";
use lib "$FindBin::Bin/../../xCAT-server/lib/perl";

Because of those FindBin paths the tests only work from a source tree. The copy installed under /opt/xcat/share/xcat/tools/autotest/unit is not a substitute -- ../.. resolves to /opt/xcat/share/xcat/tools there and the tests die or silently skip. The CI takes a copy of the checkout before the build for this reason; see preserve_source_tree().

What does not belong here

Anything that needs an installed xCAT, a populated /install, a real service binary or a live daemon. Those go in ../integration and run on a management node through xcattest. Both suites run on every pull request -- the workflow installs xCAT on the runner and then runs the ci_test cases against it -- so putting a test in integration/ does not cost it CI coverage. What differs is what each suite is allowed to depend on, and that unit tests also run standalone from a bare checkout with no xCAT at all.

The distinction matters because a test that needs an absent environment does not fail -- it calls plan skip_all and reports as skipped. A handful of those in a suite of several hundred assertions is easy to stop reading. Keeping the two kinds in separate directories means a skip in unit/ is a real signal rather than routine noise.

Guarding on a source file, on the other hand, is fine and common here:

plan skip_all => "compute.subiquity.tmpl not found" unless -f $tmpl_path;

That guard never fires when the tree is intact.