GlossaryCustom Executor

Custom Executor

A custom executor is a user-defined, containerized component that lets a test orchestration platform run tests with any tool, framework, or script beyond built-in options.

Table of Contents

Table of Contents

What Does a Custom Executor Mean?

A custom executor is a user-defined component that tells a testing platform how to run one kind of test. In Testkube, executors were containerized components for running test types like Postman, Cypress, or JMeter.

Custom executors let teams go beyond built-in options and bring their own languages, frameworks, or in-house tools.

Custom Executors vs. Test Workflows

Testkube has since moved from executors to Test Workflows. Workflows can run any container image directly, so a separate executor is no longer required.

Aspect Custom Executor (Legacy) Test Workflow (Current)
Setup Build an image and register an executor resource Reference any container image in a workflow step
Flexibility One tool per executor Multiple tools and steps in one workflow
Extras Limited setup and teardown Setup, services, parallelism, and artifacts built in
Status Superseded Recommended approach

Why Custom Test Execution Matters

Not every team uses the same tools. Some rely on niche frameworks, proprietary scripts, or specialized logic that mainstream tools do not support.

  • Full flexibility: any tool or runtime can run
  • No lock-in: teams bring their own frameworks
  • Kubernetes-native reach: custom tests get the same scaling and isolation
  • Easier adoption: complex or regulated environments keep existing tools

How Custom Executors Worked

  1. Container image: package the testing tool and its runtime.
  2. Executor definition: register the executor with a Kubernetes custom resource.
  3. Test definition: write the test in the tool's own format.
  4. Execution: Testkube starts a pod from the image, runs the test, and collects logs and artifacts.

With Test Workflows, steps one and four remain, and the separate registration step goes away.

Real-World Use Cases

  • B2B SaaS in-house frameworks: a SaaS company runs its internal contract-test runner in Kubernetes
  • Domain-specific checks: hardware simulations or compliance validations
  • Emerging tools: new frameworks before official support exists
  • Legacy suites: older tests run in Kubernetes without rewrites

Best Practices for Running Custom Test Tools

  • Use Test Workflows: reference your image directly instead of creating executors
  • Keep images small: faster pulls mean faster runs
  • Version images: pin tags so runs are reproducible
  • Write standard results: emit JUnit XML or similar for central reporting
  • Share via Git: store workflow definitions for reuse across teams

Frequently Asked Questions (FAQs)

How do I create a custom executor in Testkube?

Executors are a legacy approach. In current Testkube, create a Test Workflow that references your container image and commands directly.

Can I use any language or framework?

Yes. Anything that runs in a container can run in a Testkube workflow step.

What is the difference between a built-in executor and a custom executor?

Built-in executors supported common frameworks out of the box. Custom executors were user-created for other tools. Test Workflows now cover both cases.

Do custom test tools scale like built-in ones?

Yes. They run as Kubernetes pods and scale the same way, including parallel runs.

Can I share custom test setups across teams?

Yes. Store workflow definitions in Git and publish images to a shared registry.

Related Terms and Concepts

No items found.