I already covered how to test helm charts and different tests you may want to run. Today, I’ll focus on helm charts acceptance tests. If you later find this article useful take a look at the disclaimer for information on how to thank me.
What are acceptance tests?
You may find many definitions of acceptance testing. When I talk about acceptance testing I mean tests which treat the app as black box. That’s similar to how a customer would do. Hence the main goal of these tests is to test that the functionality the app provides (e.g. API) meets customer requirements.
And if you don’t want to hold QA as scapegoat for developers’ sins, you’d rather automate acceptance tests or let QA do that. So, eventually, acceptance tests will run as part of the release pipeline. This will ensure that the app can be safely deployed to higher environments (e.g. for performance testing). Moreover, automating acceptance testing enables automatic continuous deployment to production.
What are helm chart acceptance tests?
In short, acceptance tests of helm charts test that the chart can be successfully deployed and the functionality the helm chart provides.
Such testing, if implemented properly, will boost the confidence of chart’s clients (human or other apps) that the chart will most likely function properly in production. To facilitate acceptance testing,
helm client provides
helm test command. This command will spin up a
test container which will run the tests against deployed chart public APIs. We have already seen an example of using this command when we deployed helm Jenkins chart to minikube in docker and tested it. You can find an example of helm acceptance tests at Jenkins helm chart on GitHub.
To achieve fully automatic helm acceptance testing (e.g. in Release pipeline), you’d need to automate below phases:
- creation of Kubernetes cluster on-demand
- deployment of the helm chart to the cluster
- running the acceptance tests (
- delete chart
- delete chart’s resources (e.g. dynamically provisioned storage)
- delete cluster
Helm charts acceptance testing demo
I’ll show a demo of Jenkins helm chart’s acceptance testing.
In order to deploy a helm chart, we’ll need a Kubernetes cluster.
For demo purposes, I’ll create a Kubernetes cluster on Linode using linode-cli. You can repeat this demo on your own Linode account. Create one and get 100$ credit using this link.
In addition to the Kubernetes cluster, you’ll need
helm installed on your local machine.
Below demo assumes you downloaded
kubeconfig of the cluster and set it as
kubectl config context.
Create Kubernetes cluster on demand
linode-cli lke cluster-create --label cluster12345 --region us-central --k8s_version 1.25 --node_pools.type g6-standard-4 --node_pools.count 1 --format id --text --no-headers
The command will return the cluster’s id. We’ll use this id in subsequent commands.
Wait till the cluster is provisioned and save the cluster’s
linode-cli lke kubeconfig-view [cluster_id] --text --no-headers | base64 -d > /tmp/test-config.yaml
Deployment of the helm chart to the cluster
Let’s install community Jenkins helm chart using
helm repo add jenkinsci https://charts.jenkins.io helm repo update helm install jenkins -n jenkins jenkinsci/jenkins --kubeconfig /tmp/test-config.yaml --create-namespace --wait --debug
We have already used this chart while exploring Jenkins Docker in Docker agent and discovering how to backup Jenkins using file system snapshots.
After several minutes Jenkins chart is installed and deployed. Make sure all is good:
kubectl get all -n jenkins --kubeconfig /tmp/test-config.yaml NAME READY STATUS RESTARTS AGE pod/jenkins-0 2/2 Running 0 4m55s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/jenkins ClusterIP 10.128.106.196 <none> 8080/TCP 4m56s service/jenkins-agent ClusterIP 10.128.229.43 <none> 50000/TCP 4m56s NAME READY AGE statefulset.apps/jenkins 1/1 4m56s
It’s important to note that Linode dynamically provisioned storage and CSI volume for us where Jenkins data is stored:
kubectl get pv --kubeconfig /tmp/test-config.yaml NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-ebd3a8289cdd4f33 10Gi RWO Retain Bound jenkins/jenkins linode-block-storage-retain 7m5s
Running helm acceptance tests
Let’s run the acceptance tests against the deployed Jenkins helm chart.
helm test jenkins -n jenkins --kubeconfig /tmp/test-config.yaml
After a few moments you should see below output signifying success:
NAME: jenkins LAST DEPLOYED: Fri Apr 7 21:08:38 2023 NAMESPACE: jenkins STATUS: deployed REVISION: 1 TEST SUITE: jenkins-tests Last Started: Fri Apr 7 21:21:20 2023 Last Completed: Fri Apr 7 21:21:22 2023 Phase: Succeeded TEST SUITE: jenkins-ui-test-dtgoy Last Started: Fri Apr 7 21:21:23 2023 Last Completed: Fri Apr 7 21:21:30 2023 Phase: Succeeded
- delete Jenkins chart:
helm delete jenkins -n jenkins --kubeconfig /tmp/test-config.yaml
- delete Jenkins data volume:
kubectl delete pv pvc-ebd3a8289cdd4f33 --kubeconfig /tmp/test-config.yaml # find out CSI volume id linode-cli volumes list linode-cli volumes delete [volume_id]
- delete cluster:
linode-cli lke cluster-delete [cluster_id]
Of course to achieve full automation of helm acceptance tests, you’d need to automate the above steps.
That’s it about acceptance testing of helm charts. As always, feel free to share.
If you found this article useful, take a look at the disclaimer for information on how to thank me.
You may also find below articles interesting:
- Become a Certified Kubernetes Administrator (CKA)!
- Become a Certified Kubernetes Application Developer (CKAD)!
- BUNDLE KUBERNETES FUNDAMENTALS & CKA CERTIFICATION (COURSE & CERTIFICATION) FOR THE BEST DEAL! $499 ONLY!
Helm courses on Pluralsight:
- Packaging Applications with Helm for Kubernetes
- Automating Kubernetes Deployments Using a GitOps Workflow
Sign up using this link to get exclusive discounts like 50% off your first month or 15% off an annual subscription)
Recommended Kubernetes books on Amazon: