Testing

Testing

make check-host         # no root, no NIC, no testbed
sudo make check         # the above plus the XDP program
sudo make check-netns    # end-to-end on veth and namespaces
sudo make check-frr      # scenarios against stock FRR bfdd in containers

What each covers

target	needs	covers
check-host	nothing	ABI pins, HMAC vectors, the state machine, the bfddp parser, the receive decision, the tx_cfg derivation
check	root, a BPF kernel	the above, plus the XDP program driven through BPF_PROG_TEST_RUN
check-netns	root	the userspace receive drains through real sockets and cmsgs, then the end-to-end suite on veth and namespaces
check-frr	root, podman or docker	graceful restart, poll sequences and multihop against stock bfdd

check-host is the one a contributor can always run: it needs no libbpf, no BPF-capable kernel and no hardware, and it finishes in seconds.

Rigs that need hardware

tests/testbed/ holds things that assert but cannot run in CI:

• inject_matrix.py drives a frame matrix at a live mesh and asserts on the program's counters. It also runs as a pre-push hook, which skips when there is no testbed, because a hook that fails on an unrelated machine gets disabled and a disabled hook catches nothing.
• netns_userspace.py is the socket-level parity rig, run by check-netns.
• v6_echo_wire.py drives a real IPv6 echo and asserts on the wire rather than on counters. It needs a neighbour whose forwarding sysctl can be flipped, so nothing invokes it automatically.

Fuzzing

dp_fuzz covers the bfddp parser and xdp_fuzz the XDP program, both under libFuzzer. The nightly workflow searches; the known-findings corpus under tests/unit/fuzz-regress/ is replayed on every push, which is the cheap half.

Instruments

Measurement tools, as opposed to tests, live on the docs branch under measure/ and matrix/. They produce numbers rather than pass or fail.