Modern products have become very demanding from a quality perspective. Cloud made new things possible, and high-level cloud services simplified a lot. But, at the same time, it introduced additional complexity and made quality assurance more challenging. Testing a single microservice is simple, but ensuring everything works as expected is at least problematic.

That's one of the reasons why quality and testing approaches also had to evolve significantly. Quality and Testability aren't just the last steps of software development anymore, but an integral part of it - they have become a mindset. 

_Being able to get complete quality feedback anytime is essential._

Automated testing is the way to go - it helps detect possible defects and provides consistent feedback after every action. But, the feedback needs to be both complete and fast. Functional tests on different levels may be required - Unit, integration, API, or high-level E2E tests. And you may also need non-functional ones, like performance or security tests. That's quite a lot - designing and implementing all of these tests can already be a complex task. Additionally, multiple various tools may need to be integrated. And all of these tests will also need to be executed fast to get the feedback instantly.

If you create the custom test execution infrastructure from scratch, it can quickly get very complicated. Creation and maintenance would even become more time-consuming than actual test implementation! It means this time will be spent on something that's just the prerequisite and can distract you from focusing on actual tests. After all, the goal is to run the tests and get feedback fast. [Testkube](http://testkube.com) makes the creation of test execution infrastructure and maintenance simple compared to "standard" approaches. And less distraction and context switching also means better efficiency.

[Multiple predefined Testkube executors](https://kubeshop.github.io/testkube/category/test-types) are available out of the box and allow you to run the complete set of tests on different level, including:

* API tests -  Curl, Postman, and SoapUI executors

* Java based tests -  Both Maven and Gradle are available

* Performance tests - K6 or Artillery.io

* Ginkgo is available for Go Unit and Integration tests 

* E2E or UI tests - Cypress

* Security tests -  ZAP

* Or... you can create your own custom executor to run any other type of test

How much time would you need to spend configuring all your tools separately? And...what if you wanted to have any kind of unification?

## Testkube - A Unified Experience

No matter which of the Testkube executors you use, you can interact with them in the same way. Test, Testsuite, Execution abstractions, and Custom Resources also make it easier to focus on what's actually important - *tests*. You can interact with them directly, in the way that suits you.

## Complete set of tools

Testkube implements TestOps concepts, but you can use it in the way that best suits your needs. You can go with GitOps, and use CRDs. You can also use CLI or even create custom scripts on top of it. And, because Testkube extends kubectl, you can still use all of its features.

If you prefer Graphical User Interfaces, you can use Dashboard, which allows you to create Tests or Test Sets and conveniently view execution results and logs.

## Straightforward Transition

But the unification doesn't mean you will need to change anything on the testing side. One of the Testkube advantages is the ease of transition. You don't need to adjust or rewrite the current tests to benefit from using Testkube. There is no need to learn some new and complex tool or framework. You can start using Testkube with your existing tests, and the transition process can be pretty straightforward.

## Example project

So, let's see how fast configuring Testkube for an example project is. In this case, Cypress is used for E2E and integration tests, SoapUI is used for API tests, and K6 is used for performance checks. Additionally, curl is used for health checks, which need to run periodically. The directory structure looks like this:

Let's assume you already have Kubernetes clusters you can use, and Testkube is installed (installation instructions are available here: [https://testkube.kubeshop.io/download](https://testkube.kubeshop.io/download)). 

## Test - Custom Resource Definition

So, let's start with creating a `crd` directory, where we will put all Test Custom Resource Definitions (CRD).

You don't even need to write CRDs yourself - they can be autogenerated by both the Dashboard and CLI (with `generate test-crds` or `--crd-only` params). 

## Cypress End to End Tests

Let's configure the Cypress E2E tests first. Go to the dashboard, or open it with `tk dashboard`, then click `Add new test`, and fill in the Test details.

Hit the `Create` button, and that's all - your test has been created. But, by default, it will run all of the cypress tests available. You can add run parameters by opening test Settings and then Variables & Secrets. 

Now, you can get the CRD by going to test Settings and then Definition. All you need to do is copy it into the `crd` directory (for example, cypress-e2e.yaml file).

‍

So, it's time to describe it. 

First, `apiVersion` and `kind: Test` are Testkube's custom resource types.

Then `metadata` defines the test name and the namespace where it will be created (by default, `testkube`).

The test `spec` describes the test type (in this case, `cypress/project`) and source (the directory from a git repository). And, in the end, `executionRequest` `args` - arguments that will be passed to the cypress binary. You can create a similar Test with a different argument (`--component`) to run your Cypress component tests.

## Curl test

Now, the curl test which is used as a health check. This time, let's create the definition directly - in `test/crd/curl-healthcheck-cron.yaml` file:

The definition is similar to the previous one. The main difference is the test type (`curl/test`), and source (content type), which will be a single file from the git repository (git-file) configured with `path`.

`schedule: */5 * * * *`

Additionally, there is a test `schedule` - CRON trigger, which will execute the test periodically (in this case, every 5 minutes).

You can apply this CRD with kubectl apply:

`$ kubectl apply -f test/crd/curl-healthcheck-cron.yaml`

`test.tests.testkube.io/curl-healthcheck-cron created`

And that's all! The curl health check will run automatically every 5 minutes. 

Configuration of other executors is pretty similar, and should be straightforward now.

## So, why not check it out yourself?

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!

## And, some exciting new features are coming soon!

New features are coming soon that will speed up your workflows even further.

*Test sub-sets abstraction* will allow you to split Tests into smaller parts. It's designed especially for complex, long-running test sets. Initially, it will be available for Cypress executor, allowing you to split the Test into smaller parts and execute them in parallel. So, you won't need anything additional to run Cypress tests in parallel and speed up the execution even a few times.

*Event-based triggers* are designed to provide a powerful way of triggering tests based on resource states. Has the new app version been released? Or has the pod been created or updated? With event-based triggers, it will be possible to start tests automatically in case of such events. It's not only a great way of getting feedback immediately. Being able just to set the triggers will be a true timesaver compared to building complex workflows/pipelines or configuring and automating external triggers in a custom way.

*Custom images executor*

Additional executors for not yet supported tools will be added in the future. However, the custom image executor will also be introduced soon. It will allow using any custom image to run even very non-standard tests. So, as long as your custom tests can be containerized, you will be able to run them with Testkube - without the need for any custom integration. Image guidelines will also be available if you need to, for example, store some build artifacts.