How to Test in Kubernetes: A Unified Approach With Testkube
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 Open Source 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:
Conclusion
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.
Thankfully, there’s Open Source software like Testkube that makes this journey easier for everyone involved, helping you ensure the quality and reliability of your cloud native applications.
Give it a go!
Why not check it out yourself? Testkube is Open-Source and we’re always looking for feedback and contributions. Check us out at https://testkube.io
If you have any questions you can join our Discord community or, if you have any ideas for other useful features, you can create the feature requests at our Github Issues page.
If you’d like more info, or just to come say ‘Hi’ — join our Discord server and follow us on Twitter @Testkube_io. You can also email our Product Leader directly at bruno@kubeshop.io. We’re looking forward to hearing from you!
Originally published at https://testkube.io.
