Introduction

Fast time-to-market is key for successful businesses. However, delivering high-quality products quickly isn’t easy. The conventional testing processes often prove to be time-consuming, resource-intensive & not easily scalable, thus hampering the delivery process.

Parallel testing is an approach that transforms testing efficiency. By simultaneously executing tests in parallel across environments, parallel testing reduces testing time, optimizes resource usage, and improves scalability.

In this post, we’ll delve further into the concept of Parallel testing and see how Testkube helps teams to effortlessly execute tests in parallel, thereby improving their testing practices.

What is Parallel Testing?

Parallel testing is a methodology that involves running multiple tests simultaneously. These tests can be executed in the same or different environments, depending on the use case. By distributing tests across multiple environments, parallel testing overcomes the drawbacks of traditional testing practices that are time-consuming and resource-intensive.

Parallel testing comes with a suite of benefits, some of which are:

• Reduced Test Time: The main benefit of parallel testing is reduced testing time. By executing multiple tests simultaneously, parallel testing fastens the overall testing process as compared to sequential testing.

• Faster Bug Detection: Parallel testing enables faster feedback on application behavior and discovering bugs. As the overall testing time is reduced, the development team can address issues faster, leading to a more reliable product.

• Optimized Resource Utilization: Traditional testing practices lead to underutilization of resources, with many remaining idle during testing. Parallel testing maximizes resource usage by distributing workloads better.

Parallel Testing in Testkube

Testkube is a Kubernetes-native testing framework that allows you to run tests within your Kubernetes clusters by abstracting away the pain of containerizing tests. It allows the test team to store, execute and manage tests on Kubernetes clusters. It defines tests as Kubernetes CRDs to provide a modern solution for managing all your tests and scaling when needed.

Testkube allows you to perform testing either sequentially or in parallel through an intuitive UI where you can combine existing test workflows. This makes parallel testing easier for everyone. One can add any number of tests and move them around to create a scenario that works best for them.

Being a Kubernetes-native test orchestration and execution framework, Testkube has the following benefits:

• Kubernetes Native: From abstracting away the complexities of working with Kubernetes to scale automatically based on workload demands, Testkube takes full advantage of Kubernetes while helping teams focus on building their testing scenarios.

• Simplified Parallel Tests On CI/CD: Testkube decouples testing from your CI/CD, removes all the complexities, and speeds up your CI. Doing so helps reduce CI/CD bottlenecks and quickens the testing process.

• Easy to use: You don’t need to be in DevOps to run tests on Testkube! Users can interact with Testkube via CLI, GUI, or API, making it easier to work with. The intuitive and easy-to-use dashboard allows non-technical/non-DevOps people also to use Testkube.

Let us see how parallel testing works with Testkube.

How To Perform Parallel Testing in Testkube

In order to demonstrate the parallel testing capabilities of Testkube, we’ll deploy the online boutique - a popular microservice-based application - on a Kubernetes cluster. We’ll then set up two k6 Test Workflows - one to test the latency and the other to generate some load.

Pre-requisites

• Get a Testkube account.
• Kubernetes cluster - we’re using a local Minikube cluster.
• Testkube Agent configured on the cluster.

Perform the pre-requisite steps of creating a Kubernetes cluster, and configuring Testkube CLI, and Agent before proceeding.

Deploy Online Boutique

Clone the repo and deploy the online boutique application to the Kubernetes cluster.

git clone --depth 1 --branch v0 https://github.com/GoogleCloudPlatform/microservices-demo.git
cd microservices-demo/
kubectl apply -f ./release/kubernetes-manifests.yaml

Once the deployment is successful check for all the pods. Note: by default the application is deployed to the default namespace unless you specified above.

$ kubectl get pods 

NAME                                READY   STATUS  RESTARTS    AGE
adservice-7d7dd69f68-zj2k7                                    	1/1 	Running        	0              	12m
cartservice-777f69bb65-9xbm6                                  	1/1 	Running        	0              	12m
checkoutservice-bcbf96994-c4xdz                               	1/1 	Running        	0              	12m
currencyservice-8557bb8fb-rfsmv                               	1/1 	Running        	0              	12m
emailservice-57cc9b487b-zjrtx                                	1/1 	Running         0              	12m
paymentservice-759576897b-tcz6v                               	1/1 	Running        	0              	12m
productcatalogservice-7b7d78cdbb-z46bw                        	1/1 	Running        	0              	12m
recommendationservice-769cb665c4-dvdkq                        	1/1 	Running        	0              	12m
shippingservice-5d97bddcdd-l5s7s                              	1/1 	Running        	0              	12m

Access the application on your browser once all the pods come to the running state.

Tip: If you’re running this on Minikube, you can use minikube service list to get the URL of the application. You can use minikube ip to get your IP address if you’re using Minikube.

To make testing easier, we will configure a host on which the latency and load tests will run. Hence, we’ll configure the local /etc/hosts file and a host 192.168.49.2 django-test.com. Replace the IP address with your IP address.

Creating a Test Workflow

Navigate to the Test Workflows tab and click on “Add a new test workflow”

This will provide you with three options:

• Create from Wizard - use the wizard to create a Test Workflow.
• Start from an example - use existing k6, cypress, and playwright examples
• Combine existing workflows - use with existing workflows.
• Import from yaml - import your own Test Workflow.

We will choose “Create from Wizard” to create the two test workflows. 

• Provide a name for the workflow and choose the type as k6. 
• Provide a k6 version, we’ll use `0.49.0`

On the next screen, provide the source for the test file. This can either be a Git Repo, String or a file. In this case, we’ll choose ‘String’ and paste the content of the k6-load test.

‍

Below is code for k6-load test that you can use:

import http from 'k6/http';
import { check } from 'k6';
export const options = {
 vus: 50,
 duration: '20s',
};
export default function() {
 const res = http.get('http://django-test.com:30205/')
 check(res, {
   'status is 200': (r) => r.status === 200,
 })
};

In the code above, 

• we define the endpoint to be tested, in this case, the online boutique application. 
• we also define the virtual users and the duration of the test. 
• there’s a check function that checks the response to the request.

Click on next and provide the run command on the next screen. We’ll use the default `k6 run k6.js` command.

Click next to move to the Collaboration screen, where we leave things as is, and move to the final Summary page, where we’ll see the yaml specification for the test workflow we created.

Follow the same steps and create another k6-latency test workflow that will test the application's latency. Below is the code that you can use to create it:

import { check } from 'k6';
import http from "k6/http";
export default function() {
 const res = http.get('http://django-test.com:30205/')
 check(res, {
   'status is 200': (r) => r.status === 200,
   'latency is under 500ms': (r) => r.timings.duration <= 500,
 })
}

In the code above, 

• we define the endpoint to be tested, in this case, the online boutique application. 
• we have a check function that checks the request-response and tests the response latency.

By now, you should have the two test workflows k6-load and k6-latency created successfully.

Create a Combined Test Workflow

To run these two Test Workflows in parallel, we need to create a new Combined Test Workflow. To do that, click on “Add a New test workflow” button, which brings up multiple options to create a test workflow. Here, we’ll choose “Combine existing workflows”.

In the new dialog box, provide a name for the test workflow and click on the “+” button to select existing test workflows to execute, as shown below. 

You can either test workflows in parallel or sequentially. In this case, we add the k6-load and k6-latency test workflows to execute them in parallel.

Click on next and execute the combined test workflow. You will see that both the test workflows we’ve added start executing in parallel.

You can navigate to the Flowchart tab to view how the test workflows were executed.

You can even click on a specific test workflow to view the logs associated with it.

That’s how you can combine multiple test workflows to create a robust test workflow for your application. Check out our blog post on leveraging Testkube to orchestrate more complex system tests.

Dynamic Parallel Testing

What you saw was a straightforward way to perform parallel testing in Testkube. However, in more demanding scenarios, you’d have different testing tools, types of tests, and requirements for dynamic scaling based on the load and your application. 

With Testkube, you can perform dynamic parallel testing, define details like worker nodes, virtual users, and more, and take full control of your test workflow. Check out our blog post on running distributed tests in Testkube and make your testing workflows more comprehensive and robust. 

Summary

In the world of fast-paced software development, parallel testing emerges as a game changer. It overcomes the issues of traditional sequential testing and allows teams to deliver software faster. Parallel testing dramatically reduces the test time, improves scalability, and optimizes resource utilization.

In the post, we saw how Testkube makes testing extremely easy to execute multiple test workflows in parallel, thanks to the intuitive UI & a feature-loaded core. Adding & executing test workflows is quick, and everything from logs and results is right there. 

Try Testkube today to experience its full potential and the complex scenarios you can use it for. If you face any issues, remember that the entire Testkube team, plus a vibrant community of fellow Kubernetes testers, are on Slack.