Why You Should Start Testing in the Cloud Native Way

A couple of years ago, the idea of cloud native testing tools would have seemed crazy.

Why would you need specific tooling when there were already so many great products available for every conceivable testing scenario? And then along came Kubernetes and changed the game forever — and aren’t we glad it did!

Today, as we grapple with complex microservice architectures and siloed services running in a distributed cloud infrastructure, often managed by teams in remote global regions, testing our systems has become a hell of a lot harder. That’s why my fellow engineers at TestKube and I are pouring our energy into improving the cloud native testing space.

What Makes a Testing Tool Cloud Native?

Cloud native testing tools are developed specifically for cloud native environments. Most importantly, they allow you to deploy tests in your clusters, the executions are super scalable, and they are not coupled to any CI/CD framework such as Jenkins, GitHub Actions, etc.

You will be able to execute your test, see the results and manage the entire end-to-end test flow without ever having to go into your CI/CD.

I like to think of cloud native testing tools as turning your cluster into a modern car. Modern cars run diagnostic tests on themselves to show the driver what’s wrong. Why not have your clusters do the same?

Why Should I Start Testing in the Cloud Native Way?

With all the great testing tools available, from Postman to Cypress and everything in between, you might think, “I’ll just retrofit them to my use case.” And that’s absolutely OK! In fact, a lot of folks do just that for very simple scenarios. However, there’s a lot of heavy lifting that you can leave behind when you move to cloud native testing.

Decoupling the Testing Tools from Your CI/CD

Most implementations have testing activities tightly coupled with their CI/CD pipelines, which adds a lot of complexity and makes them less flexible. Here are a few signs that tell you that you may want to rethink the way you designed your CI/CD pipelines to be more agile by decoupling the testing activities:

• If you need to re-run your whole test suite or even your entire CI/CD workflow when only a single test run would suffice. This means you have too much coupling.
• You can’t re-use testing pipelines across multiple CI/CD tools and workflows
• There’s inconsistent execution and reporting for different testing tools when plugged into CI/CD workflows

Making your tests cloud native means they stop depending on a CI/CD system for their orchestration. Your CI/CD can and will be able to trigger your tests if you wish or need to, but it should no longer be an absolute necessity.

Scaling Your Tests

Cloud native tests are fantastic at scaling — often using Kubernetes to scale executions, unlike CI/CD tools which are not as scalable when you have a lot of concurrent tests wanting to be executed.

Removing the Need to Write Scripts or Add Boilerplate Code

At your current setup, for each testing tool that you want to add to your testing workflow, there’s a very high chance there’s a considerable amount of scripts, boilerplate code or some complex configuration you have to do to automate your tests and make them part of your CI/CD workflow. With cloud native tests that complexity is decreased by several orders of magnitude. They are meant to run in the cloud seamlessly without the extra work.

Using Testkube for Cloud Native Testing

With all the challenges of testing in mind, we decided to build Testkube with the goal of making all types of tests cloud native. One of its fundamental tenets is that by removing complexity related with test automation and integration, we directly lead the way for teams to do better testing.

On top of decoupling CI/CD from your tests, scaling, and removing the need for custom configurations, a few more added advantages of having a testing framework such as Testkube running inside your cluster is removing the need to containerize your tests, and circumventing issues with restricted access to the environments you want to test.

👁 Image

Standardized Reporting 

Consistently tracking metrics around QA and test pass/failure rates is so important when you’re working in global teams with countless different types of components and services. After all, without benchmarking, how can you measure success? TestKube does just that. Because it’s aware of the definition of all your tests and results, you can use it as a centralized place to monitor the pass/failure rate of your tests. Plus it defines a common result format, so you get consistent result reporting and analysis across all types of tests.

Containerizing Tests

If you run your applications in a non-serverless manner in the cloud and don’t use virtual machines, I’m willing to bet you probably use containers at this point and you might have faced the challenges of containerizing all your testing activities. Well, with cloud native tests in Testkube, that’s not necessary. You can just import your test files into Testkube and run them out of the box.

Managing Access to Restricted Environments

Having restricted access to an environment that we need to test or tinker with is an issue that most of us face at some point in our careers. It doesn’t necessarily mean that the administrators of those environments don’t trust you, but for environments where there’s a chance of a data leak or a mishap affecting the business, it is just better not to take any chances and prevent that from happening. So the best way to do it is just to expose the Testkube API inside those environments and use it to manage your testing activities without requiring you to have the same access.

Go for a Test Drive

There are a number of great testing libraries/tools out there that integrate seamlessly into Testkube such as Postman, Cypress, k6, soapUI and much more. As you have gathered, these are all really great tools, but they become even better when you use Testkube to run them in an easy and cloud native way.

Clusters running Testkube have the ability to test themselves without the need for a complex CI/CD. It allows you to have a holistic view of all your tests and cluster state.

If you see that cloud native testing can also benefit you, you should give TestKube a spin and let us know what you think and how we can make it even better? We’ve got a great live demo you can tinker with. You can install it easily or check out our repo on GitHub and give us a star, we are open source after all!

If you’d like any info, or just to come say “Hi” – join our Discord server and follow us on Twitter @Testkube_io or email me directly bruno@kubeshop.io. We’re looking forward to hearing from you!