Daniel Hilst
8f90c68c82
Two gaps in what the wire suite proves, both about traceability rather than about a new behaviour. S-31 had no wire case. A node whose chain.currstate is "boot" has an operating system and must be left to start it; a node handed a netboot script every time it powers on reinstalls itself forever, and does so silently, because each individual boot looks like a successful one. The Kea side of this is covered by dhcp_kea_plugin_intent.t, but the ISC side is built inline in addnode against a live database and cannot be reached by a unit test at all. The new case asks twice with the same MAC: once as firmware with no user class, once announcing the xNBA user class the first stage sets. Only the second request can be answered with the node's script, so only the second request can see the bug. What is asserted is S-31's own wording -- not "no boot file", which would forbid the stage-1 binary a server is entitled to send, but "not the node's xNBA script". The node is defined with netboot=xnba because only that method generates a second stage. The remaining ten scenarios already proven on the wire now say which specification scenario they prove, in the same "S-nn:" form the rest of the suite uses. That raises the scenarios cited by a wire case from 36 to 47 of the spec's 73, without running anything new -- the coverage was there and was not traceable.
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 |
| DHCP wire tests | xCAT-test/dhcptest/ |
python3 -m unittest discover -s tests, then dhcptest run -i <nic> <conf> |
| 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.
dhcptest is the odd one out: its Python unit tests and dhcptest validate
run offline like the others, but its point is the third column -- driving real
DHCP transactions on a provisioning NIC and asserting on what came back. It
talks to the server only over the wire, so it is agnostic to which DHCP
implementation is answering and to xCAT itself.
See unit/README.md, bats/README.md and dhcptest/README.md for the
detailed rules for each suite.