Testing in Kubernetes With a Unified Approach

May 22, 2023
8 min
Alejandra Thomas
Developer Advocate
Testing tools are usually not designed with Kubernetes in mind. Learn how to tackle the unique challenges of testing your cloud-native applications with a unified testing approach using Testkube.
Share on Twitter
Share on LinkedIn
Share on Reddit
Share on HackerNews
Copy URL

Table of Contents

Want to learn more about this topic? Check out our Office Hours sessions!

Start Using Testkube for Free Today

Whether you’re a DevOps, Software, or Quality Engineer, you are well aware of the importance and challenges of testing your software and infrastructure effectively at every stage of your development process. It can be a tedious task, but it’s one that’s well documented throughout the industry, with an ample variety of tools to support your testing needs.

But what happens if you’re working with containerized applications? CI/CD pipelines, workflows, and the tools you’re most familiar with are usually not designed for testing through container orchestration tools, like Kubernetes, and their complex nature, with many moving parts and elements involved, put additional strains on your testing process through new and unfamiliar challenges that require different approaches.

In this blog post, we’ll talk about the current state of testing applications running in Kubernetes, some of the unique challenges faced, and how to tackle them with Open Source software, like Testkube.

Current challenges of testing in Kubernetes

Testing in CI/CD pipelines

CI/CD pipelines can be complicated to begin with, varying from company to company and team to team. But when Kubernetes comes into the mix and you try to implement a testing system, your CI/CD pipelines get even more complex.

Let’s assume you have an application that’s deployed in Kubernetes, and you want to add a new test to your workflow. The first thing you’ll need to do is figure out how to give your CI/CD pipeline access to your cluster. You might have internal APIs that are not exposed, but if you want to run a test against it, then you’ll have to expose it either using an ingress controller or giving cluster access to your entire CI/CD pipeline.
In this scenario alone, you’re not only creating vulnerabilities from a security standpoint, but you’re also putting developers and QA testers through a bottleneck since this will have to be done by DevOps or Platform Engineers.

Adding to that, every time you want to run or debug a specific test, you find yourself having to build and execute the entire thing all over again.

Debugging and analyzing test results

Ideally, all your tests coexist within your application - but you need to have a system in place to store your test results, which can become complicated when using different tools. 

Each tool will have its own execution, reporting, and storing style, which makes developers and testers navigate through pods to read logs, debug, and analyze test executions on the go.

Visualizing test output files

Closely related to the previous challenge, it’s often complex to store and visualize Test Artifacts - which are the files that your testing frameworks produce. Some testing tools like Cypress or Playwright, for example, which are used for end-to-end tests, generate video recordings or JSON files that will need a place to live and are crucial to the testing process.

Whenever you add a new testing tool to your stack, you’ll also have to go through setting up your CI tool to upload this file into a storage bucket in your already intricate infrastructure.

Access to testing environments

Of course there’s also the challenge of having to navigate through restricted access to testing environments and the dependency that comes with having your testers or developers rely on DevOps and Platform Engineers to set up these testing environments. 

The first scenario of having to expose your internal APIs for testing is a really good example of this - making you vulnerable to security attacks.

To summarize, when testing applications deployed in Kubernetes, you may stumble across very unique pain points: 

  • Complexity of your CI/CD pipelines
  • Security and restricted access concerns
  • Lack of centralized results and cohesion between the tools you’re using
  • Difficulty to adapt and navigate for those  that aren’t familiar with Kubernetes at all. Testers should be able to focus solely on testing without forming this dependency and bottlenecks with DevOps and Platform Engineers

To address these challenges and pain points separately, there’s plenty of testing frameworks and tools including security testing, unit testing, end-to-end, integration, and load-testing tools that help you test your applications as a whole. But bringing them together, especially in a cloud-native environment, is the real real challenge.

A Unified Testing Approach

Let’s take a look at how resorting to a unified testing approach can help you tackle these challenges altogether. What does this approach entail? It entails bringing together all the aforementioned testing practices, tools, and processes to ensure that all aspects of your applications are tested thoroughly and efficiently. 

Some of the elements that make up a unified testing approach can be the use of automated, continuous, and asynchronous testing; combining different tools to test every aspect of your applications; displaying the results for all these types of tests in a centralized manner, meaning all together; and implementing DevOps practices.

By implementing a unified testing approach, you tackle several of the challenges discussed earlier and reap benefits such as consistency in your results, efficiency for your teams and testing efforts, overall quality of your software, better, streamlined collaboration across teams and between tools, and the ability to adapt easily to different testing tools and workflows, as well as to the Kubernetes environment as a whole. 

By combining all these elements into a single one, you’re also giving back that independence to testers and developers to focus solely on their testing responsibilities without having to worry too much about the ins and outs of Kubernetes.

So, how does Testkube come into play to achieve this?

Introducing Testkube for unified testing in Kubernetes

Testkube is an test execution and orchestration framework for Kubernetes that works with any CI/CD system and testing tool you need, leveraging all the capabilities of K8s to eliminate bottlenecks and help you perfect your testing workflow.

The vast majority of testing tools are not built with Kubernetes in mind, and Testkube was built to fix this. 

How can you take on a unified testing approach with Testkube?

Testkube allows you to run tests using any testing tool in one same environment, as it uses Kubernetes CRDs to manage and store your tests. It has native support for over 12 testing tools, including Postman, k6, SoapUi, Cypress, JMeter, Playwright, and lets you incorporate any other tool you need easily with the use of Custom Executors - letting you test your application as a whole and on every front. Let’s take a look at this.

Incorporating Testkube into your workflow is as simple as installing it into your existing Kubernetes cluster and adding your existing tests. 

Once you install and initiate Testkube, you can start creating tests from the CLI or Testkube’s Dashboard.

With native support for a myriad of tools, you can create as many tests as you need without sacrificing any aspect of your application. You can test your front-end, back-end, APIs, entire interface, and more.

On top of letting you bring multiple tools and frameworks in a seamless way, Testkube prioritizes the use of automated and asynchronous testing, which helps you test on the go, periodically, continuously, and under certain conditions or based on certain events using Test Suites and Test Triggers:

Finally, Testkube provides centralized metrics to  measure testing effectiveness, as well as easy access to your test output files:


The current state of testing in Kubernetes is challenging due to its complex architecture and the many moving parts involved in deploying and managing containerized applications. Because of this, testing cloud native applications can be very complicated, and navigating your CI/CD pipelines and workflows that are usually not designed for testing in Kubernetes make it even more so - but they shouldn’t be.

Give it a go!

Why not give it a go yourself? Sign up to Testkube and try one of our examples or head over to our documentation - if you get stuck or have questions, we’re here to help! Find an answer to your questions in the Testkube Knowledge Base or reach out to us on Slack. We’re eager to hear how you use our integrations!

Alejandra Thomas
Developer Advocate
Share on Twitter
Share on LinkedIn
Share on Reddit
Share on HackerNews
Copy URL