Testing
This document describes the automated testing that is done for each pull request submitted to bpfman, and also provides instructions for running them locally when doing development.
Unit Testing
Unit testing is executed as part of the build
job by running the following
command in the top-level bpfman directory.
Go Example Tests
Tests are run for each of the example programs found in directory examples
Detailed description TBD
Basic Integration Tests
The full set of basic integration tests are executed by running the following command in the top-level bpfman directory.
Optionally, a subset of the integration tests can be run by adding the "--" and a list of one or more names at the end of the command as shown below.
The integration tests start a bpfman
daemon process, and issue CLI commands
to verify a range of functionality. For XDP and TC programs that are installed
on network interfaces, the integration test code creates a test network
namespace connected to the host by a veth pair on which the programs are
attached. The test code uses the IP subnet 172.37.37.1/24 for the namespace. If
that address conflicts with an existing network on the host, it can be changed
by setting the BPFMAN_IP_PREFIX
environment variable to one that is available as
shown below.
If bpfman logs are needed to help debug an integration test, set RUST_LOG
either
globally or for a given test.
There are two categories of integration tests: basic and e2e. The basic tests verify basic CLI functionality such as loading, listing, and unloading programs. The e2e tests verify more advanced functionality such as the setting of global variables, priority, and proceed-on by installing the programs, creating traffic if needed, and examining logs to confirm that things are running as expected.
Most eBPF test programs are loaded from container images stored on
quay.io. The source code for
the eBPF test programs can be found in the tests/integration-test/bpf
directory. These programs are compiled by executing cargo xtask build-ebpf
--libbpf-dir <libbpf dir>
We also load some tests from local files to test the load-from-file
option.
The bpf
directory also contains a script called build_push_images.sh
that
can be used to build and push new images to quay if the code is changed.
Images get pushed automatically when code gets merged, however, it's still
useful to be able to push them manually sometimes. For example, when a new test
case requires that both the eBPF and integration code be changed together. It
is also a useful template for new eBPF test code that needs to be pushed.
However, as a word of caution, be aware that existing integration tests will
start using the new programs immediately, so this should only be done if the
modified program is backward compatible.
Kubernetes Operator Tests
Kubernetes Operator Unit Tests
To run all of the unit tests defined in the bpfman-operator controller code run
make test
in the bpfman-operator directory.
Kubernetes Operator Integration Tests
To run the Kubernetes Operator integration tests locally:
- Build the example test code userspace images locally.
- (optional) build the bytecode images
In order to rebuild all of the bytecode images for a PR, ask a maintainer to do so,
they will be built and generate by github actions with the tag
quay.io/bpfman-bytecode/<example>:<branch-name>
- Build the bpfman images locally with the
int-test
tag.
# in bpfman/bpfman-operator
BPFMAN_AGENT_IMG=quay.io/bpfman/bpfman-agent:int-test BPFMAN_IMG=quay.io/bpfman/bpfman:int-test BPFMAN_OPERATOR_IMG=quay.io/bpfman/bpfman-operator:int-test make build-images
- Run the integration test suite.
# in bpfman/bpfman-operator
BPFMAN_AGENT_IMG=quay.io/bpfman/bpfman-agent:int-test BPFMAN_IMG=quay.io/bpfman/bpfman:int-test BPFMAN_OPERATOR_IMG=quay.io/bpfman/bpfman-operator:int-test make test-integration
Additionally the integration test can be configured with the following environment variables:
- KEEP_TEST_CLUSTER: If set to
true
the test cluster will not be torn down after the integration test suite completes. - USE_EXISTING_KIND_CLUSTER: If this is set to the name of the existing kind cluster the integration test suite will use that cluster instead of creating a new one.