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.
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:
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:
Let us see how parallel testing works with 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
Perform the pre-requisite steps of creating a Kubernetes cluster, and configuring Testkube CLI, and Agent before proceeding.
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.
Navigate to the Test Workflows tab and click on “Add a new test workflow”
This will provide you with three options:
We will choose “Create from Wizard” to create the two test workflows.
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,
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,
By now, you should have the two test workflows k6-load and k6-latency created successfully.
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.
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.
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.
Testkube is a test execution and orchestration framework for Kubernetes that works with any CI/CD system and testing tool you need, empowering teams to deliver on the promise of agile, efficient, and comprehensive testing programs by leveraging all the capabilities of K8s to eliminate CI/CD bottlenecks, perfecting your testing workflow. Get started with Testkube's free trial today.
Related topics: