.agents/skills/cypress-to-scout-migration/references/cypress-vs-scout-differences.md
| Aspect | Cypress | Scout |
|---|---|---|
| Location | Centralized test folder (test/<solution>_cypress/) | Tests closer to the plugin (<plugin>/test/scout/) |
| Organization | cypress/e2e/<domain>/ | test/scout/ui/{tests,parallel_tests}/ |
| Aspect | Cypress | Scout |
|---|---|---|
| ESS | Basic authentication | SAML authentication |
| Serverless | SAML authentication | SAML authentication |
| Auth helpers | Custom login tasks | browserAuth.loginAsAdmin(), loginAsViewer(), loginAsPrivilegedUser(), loginWithCustomRole() |
Scout uses SAML for both ESS and Serverless, making auth consistent across environments.
| Aspect | Cypress | Scout |
|---|---|---|
| Environment per spec | Each spec runs in a clean environment | Spec files share the same environment |
| Data isolation | Automatic (clean environment) | Manual (different Kibana spaces via spaceTest) |
| Parallelization control | parallelism attribute in Buildkite YAML | workers attribute in Playwright config |
| Parallelization method | Spec files distributed between CI jobs | Tests run in parallel in same Kibana/ES instances, isolated by spaces |
Critical implication: In Scout, data created by one test may affect others. Use spaceTest + scoutSpace for isolation, and clean up in afterAll. Most Cypress tests have no cleanup logic because the environment is reset per spec. When migrating, you must independently audit what the test creates and add explicit cleanup.
Scout now runs on MKI via the Appex QA Serverless Scout pipeline. Cypress tests with @serverless tags no longer need to be kept solely for MKI coverage — Scout can replace them.
| Aspect | Cypress | Scout |
|---|---|---|
| Environment setup | Cypress creates the environment automatically | You must create the environment first |
| Server start | Automatic | node scripts/scout.js start-server --arch stateful --domain classic in a separate terminal |
| Running tests | Open Cypress UI or cypress run | node scripts/scout.js run-tests --arch stateful --domain security_complete --testFiles <path> |
| Aspect | Cypress | Scout |
|---|---|---|
| Label type | Negative tags allowed (@skipInEss, @skipInServerless) | Positive tags only (due to Playwright's design) |
| Skip mechanism | @skipInEss, @skipInServerless, @skipInServerlessMKI | No equivalent skip tags — use positive tags to include |
| Validation | No runtime validation | Scout validates UI tags at runtime |
| Cypress | Scout |
|---|---|
| Screens (selector files) | Page objects (class with locators + methods) |
| Tasks (action files) | Page object methods |
Direct cy.get() in tests | page.testSubj.locator() via page objects |
| No EUI abstraction | EUI wrappers (EuiComboBoxWrapper, EuiDataGridWrapper, etc.) |
| Aspect | Cypress | Scout |
|---|---|---|
| Serverless tier config | ftrConfig attribute in spec file | Test tags |
| Feature flags (local/CI) | ftrConfig attribute in spec file | Custom server configuration for stateless environments |
| Feature flags (MKI/cloud) | Limited — often requires @skipInServerlessMKI | Kibana Core APIs |
Spec isolation: Cypress creates a clean environment per spec file. Scout shares the environment — you must manage state explicitly.
Auto-waiting: Cypress retries commands with built-in timeout. Playwright/Scout also auto-waits on locator actions but uses different mechanisms (expect.poll(), locator assertions).
Async model: Cypress chains commands in a queue. Scout/Playwright uses async/await — more predictable control flow.
Browser context: In Scout, each test() block spins up a new browser context. Use test.step() for multi-step flows to reuse context and improve execution time.
Setup/teardown: Cypress often uses UI for setup. Scout strongly prefers API-based setup via apiServices/kbnClient.