passt/test/README.md
David Gibson e48373382f Use dhclient instead of udhcpc
For some reason, the passt/pasta tests and examples use dhclient for
DHCPv6, but in most cases use udhcpc for DHCPv4.  Change it to use dhclient
for both DHCPv4 and DHCPv6.  This means one less tool we need for testing,
plus dhclient is easily available on Fedora whereas udhcpc is not.

Note that the passt tests still rely on udhcpc indirectly because mbuto
wants to put it into the guest images it generates.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2022-06-15 09:38:10 +02:00

100 lines
3.1 KiB
Markdown

<!---
SPDX-License-Identifier: AGPL-3.0-or-later
Copyright (c) 2021-2022 Red Hat GmbH
Author: Stefano Brivio <sbrivio@redhat.com>
-->
# Scope
This directory contains test cases for _passt_ and _pasta_ and a simple
POSIX shell-based framework to define them, and run them as a suite.
These tests can be run as part of a continuous integration workflow, and are
also used to provide short usage demos, with video recording, for _passt_ and
_pasta_ basic use cases.
# Run
## Dependencies
### Packages
The tests require some package dependencies commonly available in Linux
distributions. If some packages are not available, the test groups that need
them will be selectively skipped.
This is a non-exhaustive list of packages that might not commonly be installed
on a system, i.e. common utilities such as a shell are not included here.
Example for Debian, and possibly most Debian-based distributions:
build-essential git jq strace iperf3 qemu-system-x86 tmux sipcalc bc
clang-tidy cppcheck isc-dhcp-common psmisc linux-cpupower
netcat-openbsd fakeroot lz4 lm-sensors qemu-system-arm qemu-system-ppc
qemu-system-misc qemu-system-x86 valgrind
### Other tools
Test measuring request-response and connect-request-response latencies use
`neper`, which is not commonly packaged by distributions and needs to be built
and installed manually:
git clone https://github.com/google/neper
cd neper; make
cp tcp_crr tcp_rr udp_rr /usr/local/bin
Virtual machine images are built during test executions using
[mbuto](https://mbuto.lameexcu.se/), the shell script is sourced via _git_
as needed, so there's no need to actually install it.
### Special requirements for continuous integration and demo modes
Running the test suite as continuous integration or demo modes will record the
terminal with the steps being executed, using asciinema(1), and create binary
packages.
The following additional packages are commonly needed:
alien asciinema linux-perf tshark
## Regular test
Just issue:
./run
from the `test` directory. Elevated privileges are not needed. Environment
variable settings: DEBUG=1 enables debugging messages, TRACE=1 enables tracing
(further debugging messages), PCAP=1 enables packet captures. Example:
PCAP=1 TRACE=1 ./run
## Continuous integration
Issuing:
./ci
will run the whole test suite while recording the execution, and it will also
build JavaScript fragments used on http://passt.top/ for performance data tables
and links to specific offsets in the captures.
## Demo mode
Issuing:
./demo
will run the demo cases under `demo`, with terminal captures as well.
# Framework
The implementation of the testing framework is under `lib`, and it provides
facilities for terminal and _tmux_ session management, interpretation of test
directives, video recording, and suchlike. Test cases are organised in the
remaining directories.
Test cases can be implemented as POSIX shell scripts, or as a set of directives,
which are not formally documented here, but should be clear enough from the
existing cases. The entry point for interpretation of test directives is
implemented in `lib/test`.