Loading

Migrate tests to Scout

This guide covers migrating existing FTR and Cypress tests to Scout.

Treat migration as a chance to revisit your tests and make them more robust, not a 1-to-1 port:

  1. Do your UI tests really need to be UI tests?

    UI tests (the slowest, most expensive, and most brittle kind) should be reserved for full end-to-end user flows.

    • UI tests that assert backend behavior (is a given feature available for the user? Is the table rendering the right number of items?) should be rewritten as API tests.
    • Tests that only verify a component renders correctly belong as RTL component tests.

    See Pick the right test type for complete guidance.

  2. Can your tests reuse Scout's default servers config?

    Scout's default server configuration mirrors the Cloud (MKI/ECH) setup and is shared across many suites in CI.

    Don't modify it: changes apply only to local CI servers and are silently ignored when provisioning Cloud projects or deployments (your test will behave differently in the two environments).

    A custom server config is the alternative: it boots test servers with custom settings for your suite alone, overriding Kibana's server args. It adds CI cost and only runs in local pipelines (no Elastic Cloud support), so stick with the default config whenever possible.

    Tip

    Most FTR-era setups don't need a custom config in Scout:

    • To enable a feature conditionally (no Kibana restart needed): use runtime feature flags via apiServices.core.settings() in a test spec or global setup hook. Works locally and on Cloud.

    • To ingest data: load via apiServices, kbnClient, or esArchiver in beforeAll, or in a global setup hook.

    • To set UI or advanced settings: use the uiSettings fixture.

      Reach for a custom server config only when a setting must be present at Kibana boot (for example, registering HTTP routes at plugin-setup time).

  3. Be the driver: review and understand your new tests

    We provide AI tooling to take most of the toil out of migration, but always review the AI-generated output manually. Understanding the decisions the AI made on your behalf will help you troubleshoot flaky tests down the road.

    Tip

    Some helpful questions to ask while reviewing:

    • Did we lose or gain any test coverage with the migration?
    • Should the new tests really be UI tests? Should they run in parallel?
    • Do the deployment tags look right? See Pick the right tags.
    • Can the tests reuse Scout's default test servers config?

Agentic skills in Kibana can take most of the toil out of migration. Your coding agent should pick up the skills below automatically. As always, review the AI-generated output manually.

The scout-migrate-from-ftr skill analyzes your FTR tests and drafts a migration plan. Review it, and the skill executes the migration.

The cypress-to-scout-migration skill, maintained by the Security Engineering Productivity team, ports Cypress tests to Scout. Redirect questions to the team in #security-solution-scout.

Run the scout-best-practices-reviewer skill on the migrated tests to make sure they follow our Scout best practices. The Security solution created their own version of the skill here.