Functional Test Runner (FTR)

The Functional Test Runner (FTR) is Kibana's legacy end-to-end test framework. It bootstraps a full Elastic Stack (Elasticsearch + Kibana) and runs test suites against it.

Use FTR when:

• You are maintaining or extending an existing FTR test suite
• Your test scenario is not yet supported by Scout

For new tests, prefer Scout.

FTR starts Elasticsearch and Kibana from a config file, then runs test files against the running servers. Tests use a service-based API (getService('supertest'), getService('security'), etc.) to interact with the stack.

Development workflow:

# Start servers once, keep them running
yarn test:ftr:server --config path/to/config.ts

# In a second terminal, run tests against the running servers
yarn test:ftr:runner --config path/to/config.ts
		

Useful flags:

# Run a specific test by name
yarn test:ftr:runner --config path/to/config.ts --grep "test name"

# Debug with browser open, stop on first failure
yarn test:ftr --config path/to/config.ts --debug --bail

# Run against serverless Elasticsearch
yarn test:ftr --config path/to/config.ts --esFrom serverless
		

Pros:

• Runs the full Elastic Stack
• Tests cross-plugin integration
• Supports complex server configuration

Cons:

• Slow startup (full stack boot on every run)
• Hard to debug
• Brittle tests due to shared state and timing sensitivity
• No parallel execution

The Kibana repo contains many FTR config files which use slightly different configurations for the Kibana server or Elasticsearch, have different test files, and potentially other config differences. FTR config files are organised in manifest files under .buildkite/ftr-manifests/, grouped by testing area and type of distribution:

• serverless:
  • .buildkite/ftr-manifests/ftr_base_serverless_configs.yml
  • .buildkite/ftr-manifests/ftr_oblt_serverless_configs.yml
  • .buildkite/ftr-manifests/ftr_security_serverless_configs.yml
  • .buildkite/ftr-manifests/ftr_search_serverless_configs.yml
• stateful:
  • .buildkite/ftr-manifests/ftr_platform_stateful_configs.yml
  • .buildkite/ftr-manifests/ftr_oblt_stateful_configs.yml
  • .buildkite/ftr-manifests/ftr_security_stateful_configs.yml
  • .buildkite/ftr-manifests/ftr_search_stateful_configs.yml

If you're writing a plugin outside the Kibana repo, you will have your own config file. See Functional Tests for Plugins outside the Kibana repo for more info.

You can reuse the existing api_integration setup by registering a test file in the test loader.

// src/platform/test/api_integration/apis/my_plugin/something.ts
export default function ({ getService }: FtrProviderContext) {
  const supertest = getService('supertest');

  describe('myPlugin', () => {
    it('stores text', async () => {
      const response = await supertest
        .post('/myPlugin/formatter/text')
        .set('content-type', 'application/json')
        .send({ text: 'hello' })
        .expect(200);

      expect(response.body).to.have.property('id');
    });
  });
}
		

See the CONTRIBUTING guide for more detail on running specific FTR suites.

Scout provides equivalent capabilities for most FTR use cases:

Start with Set up Scout in your plugin to add Scout alongside your existing FTR tests.