Automation CI/CD DevOps

Helm charts acceptance tests

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:

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 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
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 
pod/jenkins-0   2/2     Running   0          4m55s

NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)     AGE
service/jenkins         ClusterIP   <none>        8080/TCP    4m56s
service/jenkins-agent   ClusterIP    <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 
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
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


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.


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:


Recommended Helm courses on Pluralsight:

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: