Test Automation Tools Unite!
Test automation tools have been around for some time before cloud native applications became a trend.
When it comes to integration testing, the most common pattern I’ve observed was teams containerizing and integrating those tools into their CI/CD pipelines, and then using them to connect to each one of their Kubernetes clusters.
However, for the dozens of companies I’ve analyzed, each one of them did this in a custom way, where they built their internal custom solution to test their Kubernetes environments.
They did this because there was no open source solution that allowed teams to simply run their tests in Kubernetes without painfully going through the process of integrating their testing activities into their CI/CDs and then orchestrating their execution in Kubernetes.
Using Testkube for All Types of Testing in the Cloud
There are many different aspects of your code you want to test, be it functional or nonfunctional testing, and each testing tool does it differently. There are security tests, end-to-end tests, integration testing, load testing, UI testing and so on.
For each of these categories, there are a lot of open source tools that have their own way of working and integrating with your development life cycle.
Because each testing tool is different and each company has a different use case and ways of testing, Kubeshop.io decided to create Testkube.io to allow companies to execute tests against their microservices running in K8s in an uncomplicated way.
Testkube allows you to spend more time writing tests and less time on automation and integrating them into your development life cycle.
To do so, you can use Testkube’s built-in executors. It supports Postman, Cypress, any Java-based tool (Jmeter, Maven/Graddle), SoapUI, k6 and more every month.
Here’s an example of how you can run performance tests using k6 with Testkube. But wait, what if you use a tool that is not supported by default on Testkube? That’s why we created something called Container Executors.
Why Use Containers for Kubernetes Testing?
A Container Executor is any Docker image that includes your testing tool inside it. You don’t need anything else. By creating a lightweight container that you can just add to Testkube to run your tests, you can quickly automate new tests and make them part of your development life cycle.
Testkube will take care of the rest by orchestrating the execution of your tests using the container you created. It fetches the logs, tests artifacts, metrics and test results into its centralized database, where you can combine all the results for your different tests.
How to Build a Container Executor and Run a Test
We start by figuring out which image you need to run your test.
You may be able to find one on Docker Hub, or you can create your own using a Dockerfile and then store it in any public or private image registry.
In this example, we will perform a load test using Fortio, which is made to do load testing on Istio. The Istio developers were nice enough to maintain an updated Docker image for Fortio on Docker Hub. We will use it instead of creating our own image from scratch.
Pro Tip: Most testing tools have an image ready to use on Docker Hub. I suggest you always start there before building one yourself. ;)
There are three ways of interacting with Testkube. You can use the UI, CLI or Custom Kubernetes Resources (CRDs). I’m going to show you how to create and run a test in Kubernetes in each of these three ways.
Let’s start by defining our executor in our K8s cluster.
Creating a Container Executor
To do so, you can use Testkube’s CLI and run:
|
1 |
testkube create executor --name fortio --executor-type container --image istio/fortio:1.17.0 --types fortio-container/test |
Or use the UI:
Or if you are comfortable using YAMLs, you can define the following CRD (make sure to use executor_type: container):
|
1 2 3 4 5 6 7 8 9 10 11 12 |
``` apiVersion: executor.testkube.io/v1 kind: Executor metadata: name: fortio namespace: testkube spec: types: - fortio-container/test executor_type: container image: istio/fortio:1.17.0 ``` |
You can then take this YAML and deploy it to your K8s namespace using kubectl:
kubectl apply -f MyFortioExecutor.yaml
Executors, tests and many other entities that belong to Testkube are defined as CRDs. That’s one of the things that makes it Kubernetes native.
With the executor defined, we can start creating tests.
Creating a Test in Testkube
Let’s try a load test against Testkube’s website, at https://testkube.io/, using Testkube’s CLI:
|
1 |
tk create test --name fortio-test --type fortio-container/test --executor-args "load https://testkube.io/" |
Using the UI:
Or creating a CRD directly:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
``` apiVersion: tests.testkube.io/v3 kind: Test metadata: name: fortio-test namespace: testkube spec: type: fortio-container/test executionRequest: args: - load - https://testkube.io/ ``` |
kubectl apply -f fortio-test.yaml
Whether you use the CLI or the UI, executors and tests are always stored as CRDs by Testkube in the end.
Running the Test
Run it using the CLI:
|
1 |
testkube run test fortio-test |
Or using the UI:
That’s it! ✅
Time to Get Started Doing More Tests!
Get started with the future of your testing automation on Kubernetes by installing Testkube’s CLI or macOS, Linux or Windows, and start building your first Container Executor in just a few minutes. Or, if an official integration matches your test automation tooling right now, like Cypress.io, k6, Postman, Artillery and more, you can start executing tests with almost zero configuration.
Either way, you’re running and viewing all your Kubernetes tests from a single dashboard, allowing yourself to stop worrying about test infrastructure and focus full time on testing growth and optimization.
We have an active Discord server, and all our development happens in our open source project on GitHub. If you are up to the challenge, we would love to take your executor contributions to the main open source repository as well. Just give us a shout!
