Add a new make e2e-tests that runs end-to-end tests for the policy locally, using already an present kwctl binary.
Write e2e tests for the "Examples" cases listed in the readme.
Come up with more e2e tests if needed.
Notes
Note that the e2e tests for the policy are not run against a real cluster, but run with kwctl run, which simulates what would happen in a cluster.
One needs the json requests of the operations against the cluster (e.g: a CREATE of a Pod). These requests are what the k8s admission & mutation controller would receive. Kubewarden controller is registered with a webhook into the admission & mutation, so Kubewarden controller receives those requests, passes them to the policy, and depending if the policy accepts, rejects or mutates the request, the Kubewarden controller will forward the request to the kubernetes API for it to be taken into effect (e.g: the creation of the pod).
Once one has those json requests, one can use kwctl run to run them locally and outside of the cluster. This is how the e2e tests get run.
For obtaining the json requests, one craft them manually (from other requests saved in other policy e2e tests for example). Another option is to run the Echo policy in a real cluster, and save the requests from its logs.
For examples and inspiration, see the end to end tests of other policies. Example:
geeksambhu
commented
1 year ago
Acceptance criteria
Add a new
make e2e-teststhat runs end-to-end tests for the policy locally, using already an presentkwctlbinary. Write e2e tests for the "Examples" cases listed in the readme. Come up with more e2e tests if needed.Notes
Note that the e2e tests for the policy are not run against a real cluster, but run with
kwctl run, which simulates what would happen in a cluster.One needs the json requests of the operations against the cluster (e.g: a CREATE of a Pod). These requests are what the k8s admission & mutation controller would receive. Kubewarden controller is registered with a webhook into the admission & mutation, so Kubewarden controller receives those requests, passes them to the policy, and depending if the policy accepts, rejects or mutates the request, the Kubewarden controller will forward the request to the kubernetes API for it to be taken into effect (e.g: the creation of the pod).
Once one has those json requests, one can use
kwctl runto run them locally and outside of the cluster. This is how the e2e tests get run.For obtaining the json requests, one craft them manually (from other requests saved in other policy e2e tests for example). Another option is to run the Echo policy in a real cluster, and save the requests from its logs.
For examples and inspiration, see the end to end tests of other policies. Example:
e2e.bats: https://github.com/kubewarden/verify-image-signatures/blob/main/e2e.batstest-datafolder: https://github.com/kubewarden/verify-image-signatures/tree/main/test_datamake e2e-tests: https://github.com/kubewarden/verify-image-signatures/blob/8226a65e23044b2a67b4829af7b529d653f4aab8/Makefile#L23-L25