Skip to content

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.

 cargo test

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.

cargo xtask integration-test

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.

cargo xtask integration-test -- test_load_unload_xdp test_proceed_on_xdp

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.

export BPFMAN_IP_PREFIX="192.168.50"

If bpfman logs are needed to help debug an integration test, set RUST_LOG either globally or for a given test.

export RUST_LOG=info
OR 
RUST_LOG=info cargo xtask integration-test -- test_load_unload_xdp test_proceed_on_xdp

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:

  1. Build the example test code images.
    # in bpfman/examples
    make build-us-images
    make build-bc-images
  1. 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
  1. 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.