Daniel Hilst
e50ad8a0b3
A Windows UEFI install deferred to proxyDHCP gets boot-file-name "" in its Kea reservation. Kea treats the empty string as not specified, so the subnet classes still match the node on architecture, and xcat-uefi-x64 offers it xcat/xnba.efi instead of leaving it to the daemon on port 4011. The test syncs a proxyDHCP node and a netboot node against the real architecture classes. It expects the proxyDHCP MAC in xcat-localboot and every boot-file class to exclude that class. It fails on this tree. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
xCAT-test
Unit tests that run from the source checkout are split by implementation language:
| Test type | Location | Runner |
|---|---|---|
| Perl unit tests | xCAT-test/unit/*.t |
prove -r xCAT-test/unit |
| Shell unit tests | xCAT-test/bats/*.bats |
bats -r xCAT-test/bats |
| Black-box service tests | xCAT-test/blackboxtest/ |
python3 -m unittest discover -s tests, then blackboxtest run <conf> on a management node |
| CLI functional tests | xCAT-test/autotest/testcase/ and xCAT-test/autotest/bundle/ |
xcattest -f <cluster.conf> -t <case> or xcattest -f <cluster.conf> -b <bundle> |
Use Perl .t tests for Perl modules, Perl scripts, templates, and repository
artifacts. Use BATS tests for shell-script behavior that can be exercised from
the checkout by sourcing a shell library or script and shadowing external
commands.
Shell behavior should not be tested by Perl tests that grep shell source. Put
those tests under xCAT-test/bats instead.
blackboxtest is the odd one out: its Python unit tests and blackboxtest validate run offline like the others, but its point is the third column --
asking a management node what a booting node asks (DHCP, DNS, TFTP, HTTP,
xcatd) and asserting on the answers. It talks to the services only as a client,
so it does not depend on which DHCP server answers or on the xCAT database.
See unit/README.md, bats/README.md and blackboxtest/README.md for the
detailed rules for each suite.