2022-01-26 15:22:16 +00:00
|
|
|
<!---
|
|
|
|
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
|
2022-06-10 02:32:44 +00:00
|
|
|
clang-tidy cppcheck isc-dhcp-common psmisc linux-cpupower
|
2022-01-26 15:22:16 +00:00
|
|
|
netcat-openbsd fakeroot lz4 lm-sensors qemu-system-arm qemu-system-ppc
|
2022-03-15 19:16:13 +00:00
|
|
|
qemu-system-misc qemu-system-x86 valgrind
|
2022-01-26 15:22:16 +00:00
|
|
|
|
|
|
|
### 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
|
|
|
|
|
2022-02-22 17:29:45 +00:00
|
|
|
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.
|
2022-01-26 15:22:16 +00:00
|
|
|
|
2022-02-22 17:29:45 +00:00
|
|
|
The following additional packages are commonly needed:
|
2022-01-26 15:22:16 +00:00
|
|
|
|
2022-03-15 19:14:40 +00:00
|
|
|
alien asciinema linux-perf tshark
|
2022-01-26 15:22:16 +00:00
|
|
|
|
|
|
|
## Regular test
|
|
|
|
|
|
|
|
Just issue:
|
|
|
|
|
|
|
|
./run
|
|
|
|
|
2022-03-14 23:59:09 +00:00
|
|
|
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
|
2022-01-26 15:22:16 +00:00
|
|
|
|
|
|
|
## Continuous integration
|
|
|
|
|
|
|
|
Issuing:
|
|
|
|
|
|
|
|
./ci
|
|
|
|
|
2022-02-22 17:29:45 +00:00
|
|
|
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.
|
2022-01-26 15:22:16 +00:00
|
|
|
|
|
|
|
## Demo mode
|
|
|
|
|
|
|
|
Issuing:
|
|
|
|
|
|
|
|
./demo
|
|
|
|
|
2022-02-22 17:29:45 +00:00
|
|
|
will run the demo cases under `demo`, with terminal captures as well.
|
2022-01-26 15:22:16 +00:00
|
|
|
|
|
|
|
# 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`.
|