Kubeshop sponsored this post. Insight Partners is an investor in Kubeshop and TNS.
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.
We are a team of experienced technologists creating development and testing tools, which help teams build cloud native applications easier, better, faster. Backed by the most successful investors in the software industry who see Kubernetes as the foundation for building the software of tomorrow. Insight Partners is an investor in Kubeshop and TNS.
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:
testkube create executor --name fortio --executor-type container --image istio/fortio:1.17.0 --types fortio-container/test
Or use the UI:
👁 Image
Or if you are comfortable using YAMLs, you can define the following CRD (make sure to use `executor_type: container`):
```
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:
tk create test --name fortio-test --type fortio-container/test --executor-args "load https://testkube.io/"
Using the UI:
Or creating a CRD directly:
```
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:
testkube run test fortio-test
Or using the UI:
👁 Image
👁 Image
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!
We are a team of experienced technologists creating development and testing tools, which help teams build cloud native applications easier, better, faster. Backed by the most successful investors in the software industry who see Kubernetes as the foundation for building the software of tomorrow. Insight Partners is an investor in Kubeshop and TNS.
