Vinícius Ferrão
f4f596537e
Run complete rendered installers and their emitted postboot scripts in private Linux filesystems. Cover service selection, flag aliases, defaults, debug output, ordering and failures, and select the test in CI.
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 |
| Native host tests | xCAT-test/native/*.t |
Explicit lab runs; see native/README.md |
| 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.