github.com/cilium/cilium@v1.16.2/test/controlplane/README.md (about) 1 # Control-plane tests for the cilium agent 2 3 The control-plane tests are integration tests that validate that the agent 4 performs the correct datapath action when given Kubernetes resources as inputs. 5 6 These tests are one step down from full end-to-end tests and the test cases 7 are purposely written in terms of "k8s objects in, mock datapath state out" in 8 order to not make any assumptions about the control-plane implementation. This 9 approach caters towards: 10 11 - Regression testing. Bugs in the control-plane implementation that can 12 be reproduced in a k8s environment can be converted into a test case by 13 capturing the k8s resources that describe the state of the cluster 14 15 - Refactoring. Even large changes in the implementation of the control-plane 16 would not invalidate the test cases themselves. Only `suite/agent.go` would need 17 to be adapted. 18 19 ## Running the tests 20 21 The tests can be run as usual with Go test: 22 23 $ go test ./test/controlplane 24 25 If the test case is a golden test, the golden output files can be updated 26 with the '-update' flag: 27 28 $ go test ./test/controlplane -test.v -test.run TestControlPlane/GracefulTermination -update 29 30 For debug log output, run with '-debug' flag: 31 32 $ go test ./test/controlplane -test.v -debug 33 34 ## Writing tests 35 36 Since the tests pull in pretty much the whole agent the tests are 37 unidiomatically compiled into a single test binary to avoid long linking 38 times and producing of many large binaries. The entry point is defined in 39 controlplane_test.go, and the tests add themselves into the test suite via 40 init() by calling suite.AddTestCase. 41 42 The test cases consist of calling suite.NewControlPlaneTest to construct 43 suite.ControlPlaneTest with which one can start the agent with desired 44 configuration and update and delete K8s objects. 45 46 For representative examples see `node/nodehandler.go` (test with manually 47 constructed k8s object) and `services/nodeport/nodeport.go` (test with 48 generated k8s objects and golden test files). 49 50 ## Updating k8s versions 51 52 To update the k8s versions being tested, the only step necessary is to 53 update the `k8s_versions.txt` file and run `make update-k8s-versions 54 generate-input-files`. This make target will regenerate all auto-generated 55 input files. You may also need to run `make update-golden` to regenerate the 56 golden files, especially if you bump an existing version's patch revision. 57 58 If a new k8s version is being added, remove the oldest kind-config file and 59 manually add the new kind-config file in all directories that contain the 60 kind-configs. It is possible to list all kind-config files with `find . -type f -regextype posix-extended -regex ".*/kind-config-.*.yaml"` 61 62 It might be necessary to update the `suite/testcase.go` file with the new 63 API resources used in the k8s version.