Derek Nola
168b14b08e
* New startup integration test * Add testing section to PR template * Move helper functions to direct k8s client calls Signed-off-by: Derek Nola <derek.nola@suse.com> |
3 years ago | |
---|---|---|
.. | ||
certrotation | Integration Test: Startup (#5630) | 3 years ago |
custometcdargs | Testing directory and documentation rework. (#5256) | 3 years ago |
dualstack | Integration Test: Startup (#5630) | 3 years ago |
etcdrestore | Integration Test: Startup (#5630) | 3 years ago |
etcdsnapshot | Integration Test: Startup (#5630) | 3 years ago |
localstorage | Integration Test: Startup (#5630) | 3 years ago |
secretsencryption | Integration Test: Startup (#5630) | 3 years ago |
startup | Integration Test: Startup (#5630) | 3 years ago |
Dockerfile.test | Bump golang to 1.18.1 | 3 years ago |
README.md | Testing directory and documentation rework. (#5256) | 3 years ago |
integration.go | Integration Test: Startup (#5630) | 3 years ago |
test-runner.sh | Creation of K3s integration test Sonobuoy plugin (#3931) | 3 years ago |
README.md
Integration Tests
Integration tests should be used to test a specific functionality of k3s that exists across multiple Go packages, either via exported function calls, or more often, CLI comands. Integration tests should be used for "black box" testing.
Framework
All integration tests in K3s follow a Behavior Diven Development (BDD) style. Specifically, K3s uses Ginkgo and Gomega to drive the tests.
To generate an initial test, the command ginkgo bootstrap
can be used.
To facilitate K3s CLI testing, see tests/util/cmd.go
helper functions.
Format
All integration tests should be placed under tests/integration/<TEST_NAME>
.
All integration test files should be named: <TEST_NAME>_int_test.go
.
All integration test functions should be named: Test_Integration<TEST_NAME>
.
See the local storage test as an example.
Running
Integration tests can be run with no k3s cluster present, each test will spin up and kill the appropriate k3s server it needs.
Note: Integration tests must be run as root, prefix the commands below with sudo -E env "PATH=$PATH"
if a sudo user.
go test ./tests/integration/... -run Integration
Additionally, to generate JUnit reporting for the tests, the Ginkgo CLI is used
ginkgo --junit-report=result.xml ./tests/integration/...
Integration tests can be run on an existing single-node cluster via compile time flag, tests will skip if the server is not configured correctly.
go test -ldflags "-X 'github.com/k3s-io/k3s/tests/integration.existingServer=True'" ./tests/integration/... -run Integration
Integration tests can also be run via a Sonobuoy plugin on an existing single-node cluster.
./scripts/build-tests-sonobuoy
sudo KUBECONFIG=/etc/rancher/k3s/k3s.yaml sonobuoy run --plugin ./dist/artifacts/k3s-int-tests.yaml
Check the sonobuoy status and retrieve results
sudo KUBECONFIG=/etc/rancher/k3s/k3s.yaml sonobuoy status
sudo KUBECONFIG=/etc/rancher/k3s/k3s.yaml sonobuoy retrieve
sudo KUBECONFIG=/etc/rancher/k3s/k3s.yaml sonobuoy results <TAR_FILE_FROM_RETRIEVE>