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 (
helm test
) - cleanup:
- 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.
Prerequisites
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 kubectl
and 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 kubeconfig
afterwards.
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
:
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
Cleanup
To cleanup:
- 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.
Summary
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:
Bonus:
- 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!
Recommended 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: