JMeter integration, Timeouts, Abort, & UI features

‍

**Testkube v1.7 is now live!** This release comes with important features including a long awaited ability to define timeouts for your Tests and abort Test executions, a new JMeter integration and many updates to the UI.

## **Test Abortion & Timeouts**

It’s now possible to completely abort a Test or Test Suite execution. You can trigger this directly from the UI or through the Testkube CLI:

```bash

testkube abort <resourceName> <resourceId>

``` 

For test executions

```bash

testkube abort execution 636cf07aaea7cf841884b548

```

For test suite executions

```bash

testkube abort tse 636cf08cbea8cf841884b548 

```

By navigating to your Test Settings, you’ll also be able to set Timeouts in seconds:

Resulting in your Test being aborted if its execution surpasses the set timeout:

## **JMeter**

We’ve officially added [JMeter](https://jmeter.apache.org/) as another type of executor. You can access it while creating a Test through the Type labeled ```jmeter/test```

This allows you to easily import and execute your JMeter tests from whichever source you prefer. You can define tests as JMeter jmx files and pass it to the executor.

## **UI features**

We focused on updating and translating our most recent features into the UI. 

It’s now possible to do the following from it:

### **Test Triggers**

Test Triggers allow users to automate running Tests or Test Suites based on various Kubernetes events.

Test Triggers run an action on a defined execution (Test or Test Suite) identified using testSelector when a Kubernetes event occurs on one or multiple resources identified using resourceSelector, and it’s now possible to create them through the UI by navigating to the Triggers section on the left sidebar:

This will take you to the Triggers dashboard where you can create different types of triggers:

You can read more about Test Triggers [here](https://kubeshop.github.io/testkube/using-testkube/triggers/).

### **Test Sources**

We’ve added the ability to create Test Sources on the UI. This is also accessible through the left sidebar:

Test Sources allow you to share test content details among multiple tests. This is implemented similarly to the existing Test CRD content section with a new added Source field to Test CRD specification.

Intending to make source usage as flexible as possible, you only need to provide the required fields at source creation, without checking if a source exists at the moment of test creation.

If you use a source with your Test, you can fill only the necessary fields:

You can read more about Test Sources [here](https://kubeshop.github.io/testkube/openapi/#tag/test-sources).

### **Custom Executors**

You can now create and add Custom Executors to run any type of tests through the UI.

You’ll need to provide your Executor’s name, type, and its container image as shown in the fields below:

‍

You can find a more detailed explanation on how to integrate your own Custom Executors [here](https://kubeshop.github.io/testkube/test-types/executor-custom/#creating-a-custom-executor).

## **Livestream**

Interested in seeing how it all works? Catch the Testkube team’s demo on the v1.7 release through our livestream [here](https://www.youtube.com/watch?v=yDiDcR33l2k).

## **Give it a go!**

Feel free to have a look at the new updates available and let us know what you think or how to make Testkube better!

We’ve got a [great demo](https://demo.testkube.io/) you can play with and you can download the release from [GitHub](https://github.com/kubeshop/testkube).

If you’d like more info, or just to come say ‘Hi’ – join our [Slack](https://bit.ly/testkube-slack) and follow us on Twitter [@Testkube_io](http://twitter.com/testkube_io). You can also email us directly at [bruno@kubeshop.io](mailto:bruno@kubeshop.io). We’re looking forward to hearing from you!