How to Integrate Testkube with Helm for Easier Test Management

We all have seen the revolution that cloud native has brought to application development. It has fundamentally changed how organizations build, package, and deploy applications but the complexity of ensuring application quality across environments continues to escalate. 

Helm is one tool that has established itself as the de facto standard for Kubernetes application packaging and deployment. Still, organizations have yet to fully capitalize on Helm’s potential for standardizing and automating testing procedures.

In this blog post, we’ll examine integrating Testkube with Helm to create a unified approach to application development and quality assurance. 

Understanding Helm

As the official “package manager for Kubernetes,” Helm enables developers to define, install, and upgrade applications through charts—packaged collections of pre-configured Kubernetes resources. These charts are templates customized through values files, allowing you to configure environment variables while maintaining consistency. 

By abstracting away the complexity of raw Kubernetes yaml files, Helm allows teams to manage the application lifecycle more efficiently, track version history, and roll back to previous versions when necessary. This has allowed teams to create standardized deployments across multiple environments. 

Testing your Helm Deployments

While Helm’s capabilities for application packaging and deployment are widely recognized, its testing potential remains largely unexplored. Implementing a robust testing approach for your Helm-deployed applications ensures they work as intended before promotion to production environments.  Helm allows you to use the same templating, versioning, and dependency management features to create consistent, reproducible testing environments. This allows teams to treat tests as first-class citizens in their cloud native environment. 

• Consistency across environments: Helm allows test configurations to be templated and parametrized, like application charts, ensuring tests run identically across development, staging, and production environments. 
• Version Control for Test Configurations: It allows you to track changes to test setups over time with the same versioning as application deployments. 
• Simplified Rollbacks: When new approaches prove problematic, you can easily revert to previous test configurations, maintaining testing integrity alongside application versioning.
• Integration with CI/CD Pipelines: Leverage existing Helm-based workflows to incorporate automated testing as part of the deployment process

What is Testkube?

While Helm provides an excellent foundation for packaging and potentially managing tests, Testkube elevates cloud native testing by offering a dedicated, cloud native test execution framework. Building upon the packaging and versioning capabilities discussed in the previous section, Testkube takes a specialized approach to testing that complements Helm's strengths by offering: 

• Kubernetes-Native Testing Architecture: Testkube runs tests directly in your cluster, leveraging the same infrastructure used for your applications. This ensures that tests accurately reflect real-world conditions.
• Multi-Framework Support: It seamlessly integrates with popular testing frameworks like Postman, K6, Cypress, and JMeter, providing flexibility without requiring complex configuration.
• Declarative Test Management: Define tests as Kubernetes custom resources that can be version-controlled alongside Helm charts, creating a unified approach to both application deployment and testing.

By integrating Testkube with Helm, teams can create a powerful synergy that addresses application packaging and testing needs within Kubernetes environments. By combining Helm's robust templating and versioning capabilities with Testkube's specialized testing framework, organizations can establish a unified approach to cloud-native deployment and quality assurance. 

Integrating Testkube With Helm

To better understand the synergies, we’ll do a hands-on demo of integrating Testkube with Helm. We’ll use the online boutique microservices application. Create a k6 Test Workflow that will validate one service of the application. We’ll use Helm to deploy the application to the cluster and execute the k6 Test Workflow to validate our application. 

The application is deployed in the default namespace, and Testkube is installed in its own testkube namespace. We have configured the Testkube agent to execute Test Workflows using a different namespace.

Prerequisites

• Kubernetes cluster - For this demo, we'll be using a local Minikube cluster, but any Kubernetes cluster will work.
• Helm - Installed and configured on your local machine with access to your cluster.
• Testkube account - Sign up for a Testkube account to access the testing platform.
• Testkube agent - Properly configured and running on your Kubernetes cluster.
• Testkube credentials - Have your API Token, Organization ID, and Environment ID ready for configuration.
• kubectl - Configured with access to your Kubernetes cluster for verification and troubleshooting

To create the API token, refer to our API Token document. To find the Org ID and environment IDs, go to your Testkube Dashboard and click Settings from the menu bar.

Once you meet the prerequisites, you can start a target Kubernetes cluster using a Testkube agent setup. You also need to clone the online boutique microservices application as we need to add a Test Workflow to the helm charts.

Creating k6 Test Workflow

The Online boutique microservices application has many microservices, but we’ll focus on the ‘frontend’ service, which is responsible for the application's front end. The k6 Test Workflow that we’ll create will validate the homepage and loading of the frontend service. You can refer to our guide on creating a Test Workflow to create a Test Workflow.

kind: TestWorkflow

apiVersion: testworkflows.testkube.io/v1
metadata:
	name: online-boutique-service
    namespace: testkube
    labels:
    	test-workflow-templates: "yes"
spec:
	use:
    - name: official/k6/v1
    config:
    	appUrl:
        	type: string
            default: http://localhost:8080
content:
	files:
    - path: /data/k6.js
      content: |       
      	import http from 'k6/http';
        import { check, sleep } from 'k6';
        
        export default function() {
        // The appUrl will be passed by Testkube when running the test
        const appUrl = '{{ config.appUrl }}';
        
        // Make a request to the frontend page
        const res = http.get(appUrl);
        
        // Check if the response was successful and met performance criteria
        check(res, {
        	'status is 200': (r) => r.status === 200,
            'response time < 1000ms': (r) => r.timings.duration < 1000,
            'body contains Online Boutique': (r) => r.body.includes('Online Boutique')
        });
        
        sleep(1);
        }
        
container:
	workingDir: /data
status: {}

This K6 Test Workflow checks the frontend service's status to HTTP 200. The response time is under 1000ms, and the body contains the text “online boutique.”

Once the Test Workflow is created, you can add it to Testkube through the dashboard and click on the Create button to save it, or you can use the Testkube CLI to create a Test Workflow.

Creating a Helm Test

After you’ve created the k6 Test Workflow, the next step is to create a helm test. To do that, you must create a new folder called tests inside the templates folder and add a test.yaml - /helm-charts/templates/tests/test.yaml.

apiVersion: batch/v1
kind: Job
metadata:
	name: "{{ .Release.Name }}-testkube-test"
    annotations:
    	"helm.sh/hook": test
spec:
	template:
    	spec:
        	containers:
            	- name: testkube-runner
                image: kubeshop/testkube-cli:latest
                env:
                	- name: TESTKUBE_API_KEY
                      valueFrom:
                    	secretKeyRef:
                        	name: testkube-credentials
                            key: apiKey
                    - name: TESTKUBE_ROOT_DOMAIN
                      valueFrom:
                      	secretKeyRef:
                        	name: testkube-credentials
                            key: rootDomain
                    - name: TESTKUBE_ORG_ID
                      valueFrom:
                      	secretKeyRef:
                        	name: testkube-credentials
                            key: orgId
                    - name: TESTKUBE_ENV_ID
                      valueFrom:
                      	secretKeyRef:
                        	name: testkube-credentials
                            key: envId
         command: ["/bin/sh", "-c"]
         args:
         - |
         	echo "Starting test job..."
            
            # Set up Testkube context with authentication
            echo "Setting up Testkube context..."
            testkube set context \
            	--api-key "$TESTKUBE_API_KEY" \
                --root-domain "$TESTKUBE_ROOT_DOMAIN" \
                --org-id "$TESTKUBE_ORG_ID" \
                --env-id "$TESTKUBE_ENV_ID"
                
            # Get frontend service URL
            FRONTEND_URL="http://frontend.{{ .Release.Namespace }}.svc.cluster.local:80"
            echo "Target frontend URL: $FRONTEND_URL"
            
            # Run the testworkflow
            echo "Running testworkflow online-boutique-service..."
            testkube run testworkflow online-boutique-service --config appUrl=$FRONTEND_URL
            
            # Save the result
            RESULT=$?
            echo "Result code: $RESULT"
            
            if [ $RESULT -eq 0 ]; then
            	echo "Test passed!"
                exit 0
            else
            	echo "Test failed with status code: $RESULT"
                exit 1
            fi
    restartPolicy: Never 
backoffLimit: 0

The above file:

• Creates a Kubernetes job that we can execute using helm test command. 
• Add a helm.sh/hook: test annotation, which is mandatory to execute the helm test. 
• Add secrets for Testkube tokens and IDs to set the Testkube context.
• We’ll use the Testkube CLI to execute the online-boutique-service Test Workflow.
• Save the result and share the output based on the result.

Deploying and Testing the App

Now that the file is created and saved, you can install the Online Boutique Microservices application.

helm install online-boutique ./helm-chart
NAME: online-boutique
LAST DEPLOYED: Thu Mar 13 11:43:07 2025
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
Note: It may take a few minutes for the LoadBalancer IP to be available.‍

Watch the status of the frontend IP address with:
	kubectl get --namespace default svc -w frontend-external‍
    
Get the external IP address of the frontend:
	export SERVICE_IP=$(kubectl get svc --namespace default frontend-external --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
    echo http://$SERVICE_IP

You can validate the application by navigating to the URL of the frontend or frontend-external service. 

You can execute the test using the helm test command.

helm test online-boutique
NAME: online-boutique
LAST DEPLOYED: Thu Mar 13 11:43:07 2025
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: 	online-boutique-testkube-test
Last Started:   Thu Mar 13 12:38:11 2025
Last Completed: Thu Mar 13 12:38:24 2025
Phase:      	Succeeded
NOTES:
Note: It may take a few minutes for the LoadBalancer IP to be available.‍

Watch the status of the frontend IP address with:
	kubectl get --namespace default svc -w frontend-external‍
    
Get the external IP address of the frontend:
	export SERVICE_IP=$(kubectl get svc --namespace default frontend-external --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
    echo http://$SERVICE_IP

While the test executes, you can use the kubectl logs command to check the status of the job.

kubectl logs job/online-boutique-testkube-test
Starting test job...
Setting up Testkube context...
Your config was updated with new values 🥇‍

Your current context is set to cloud‍

	Organization   : Atulpriya Sharma-personal-org (tkcorg_f512345678905)
    Environment	: local-minikube (tkcenv_c61234567890)
    API Key    	: tk*********************************45
    API URI    	: https://api.testkube.io
    Namespace  	:‍
    
Target frontend URL: http://frontend.default.svc.cluster.local:80
Running testworkflow online-boutique-service...‍

Context: cloud (2.1.113)   Namespace:	Org: Atulpriya Sharma-personal-org   Env: local-minikube

-------------------------------------------------------------------------------------------------‍

Test Workflow Execution:
Name:             	online-boutique-service
Execution ID:     	67d284658a39eb7e9328700c
Execution name:   	online-boutique-service-20
Execution namespace:
Execution number: 	20
Requested at:     	2025-03-13 07:08:20.623179958 +0000 UTC
Disabled webhooks:	false
Running context:
Interface:
	Type:             	cli
Actor:
	Name:             	noreply@testkube.io
    Email:            	noreply@testkube.io
    Type:             	user
Status:           	queued‍

$ Watch test workflow execution until complete \
	kubectl testkube watch twe 67d284658a39eb7e9328700c
    
$ Use following command to get test workflow execution details \
	kubectl testkube get twe 67d284658a39eb7e9328700c
Result code: 0
Test passed!

You can validate this by visiting the Testkube dashboard and checking the status of the Test Workflow. 

With Testkube and Helm successfully integrated, you now have a powerful framework for cloud native testing that leverages the best of both technologies. This approach streamlines your testing process and ensures consistency and reliability across your deployment pipeline.

Get Started with Testkube and Helm

In this post, we saw how this combination leverages Helm's powerful packaging and templating capabilities alongside Testkube's testing framework to create a comprehensive solution for quality assurance in Kubernetes environments. 

For architects and technical decision-makers, this integration streamlines workflows by treating both application deployment and testing as version-controlled, declarative resources within the same ecosystem. By adopting this approach, organizations can achieve greater consistency across environments, faster feedback cycles, and improved confidence in their cloud-native applications. 

Get started today and discover how Testkube can transform your testing strategy. You can also join our Slack community to start a conversation or read Testkube documentation to see how Testkube can enhance your testing workflow, ensuring seamless, efficient, and automated testing within the Kubernetes environments. 

‍