| name | scout-migrate-from-ftr |
| description | Single entry point for migrating Kibana Functional Test Runner (FTR) tests to Scout. Plans the migration first, asks the user to review the plan, then executes it and runs the new tests. Use when migrating FTR tests to Scout, triaging FTR suites for Scout readiness, deciding UI vs API vs RTL/Jest, mapping FTR services/page objects/hooks to Scout fixtures, or splitting loadTestFile patterns. |
Migrate FTR to Scout
Overview
This is the single entry point for FTR-to-Scout migrations. It runs a deliberate five-step workflow:
- Plan — analyze the FTR suite end-to-end and write a migration plan document.
- Review gate — stop. Surface key warnings to the user and wait for explicit approval before writing or moving any test code.
- Execute — once approved, do the actual conversion.
- Run and iterate — run the new tests, iterate on failures, and stop only when they pass (or the agent needs human help).
- Review parity & best practices — apply the
scout-best-practices-reviewer skill to verify migration parity and Scout best-practice compliance.
The review gate is the point of the workflow. The plan front-loads decisions (UI vs API vs RTL/Jest, parallelism, auth, Cloud portability, batching) so the user can correct course cheaply, before any code is rewritten. Do not skip it.
Inputs
Before starting, collect or confirm:
- FTR directory path: the root of the FTR suite(s) to analyze (e.g.
x-pack/platform/test/functional/apps/dashboard).
- FTR config path(s): the config file(s) that wire these tests. Walk up from the test directory if not provided.
- Target Scout module root: where the Scout tests will live. If unknown, infer from the plugin that owns the FTR tests.
- : stateful, serverless, or both. Default: both.
