在你的插件或包中设置 Scout

本页面展示了向插件/包添加 Scout 测试的最简设置。关于选择正确的导入方式（@kbn/scout 与解决方案包），请参阅 Scout 包。

使用 Scout CLI 进行引导式设置

生成可用的脚手架

按照引导式设置生成可用的脚手架（文件夹、配置和示例测试）
```
node scripts/scout.js generate
		
```
该命令还会通过更新 .buildkite/scout_ci_config.yml 文件，自动在 CI 中启用你的插件或包的 Scout 测试。
编写并运行测试

调整新的 Playwright 配置，并编写 UI 测试或API 测试。

手动设置

创建文件夹布局

创建 test/scout
```
your-plugin/
└── test/
    └── scout/
        ├── ui/
        ├── api/
        └── common/
		
```
1. UI 测试（可选）
2. API 测试（可选）
3. 共享代码（可选）
提示

大型插件通常会积累不同功能区域的测试，这些区域有时由不同的团队负责。与其将它们全部直接放在 Scout 根目录下，不如将它们归组到功能区域命名空间中，并为每个区域指定所有权。
创建 Playwright 配置

在 test/scout/ui 和/或 test/scout/api 下创建一个配置。
标准配置（顺序运行测试）
创建 playwright.config.ts
import { createPlaywrightConfig } from '@kbn/scout'; export default createPlaywrightConfig({ testDir: './tests', });
重要提示

使用约定俗成的名称 playwright.config.ts，以便 Scout 工具可以发现该配置。

然后在配置文件旁边创建 tests/ 目录。

如果许多文件共享一次性设置（存档/摄取/设置），请添加一个全局设置钩子。
并行配置（并行运行测试）
如果你的 UI 套件可以隔离，请在 test/scout/ui 下添加 parallel.playwright.config.ts 并将其指向 parallel_tests/
import { createPlaywrightConfig } from '@kbn/scout'; export default createPlaywrightConfig({ testDir: './parallel_tests', workers: 2, });
重要提示

使用约定俗成的名称 parallel.playwright.config.ts，以便 Scout 工具可以发现该配置。

然后在配置文件旁边创建 parallel_tests/ 目录。对于并行套件，建议使用 spaceTest 定义测试套件和测试用例，以便每个工作线程都在隔离的 Space 中运行（参见并行性）。

如果许多文件共享一次性设置（存档/摄取/设置），请添加一个全局设置钩子。
在 CI 中启用 Scout 运行

确保你的插件或包已列在 .buildkite/scout_ci_config.yml 中，以便 Scout 测试在 CI 中运行。如果尚未列入，请在适当的 enabled 列表下添加一行
- 插件：在 plugins.enabled 下添加 - <plugin_name>。名称是 plugins/ 之后的路径片段（插件文件夹名称，或嵌套插件的斜杠分隔路径）。
- 包：在 packages.enabled 下添加 - <package_name>。名称是 packages/ 之后的文件夹名称。
```
plugins:
  enabled:
    - <plugin_name>
  disabled:

packages:
  enabled:
    - <package_name>
  disabled:
		
```
编写并运行测试

调整新的 Playwright 配置，并编写 UI 测试或API 测试。

使用命名空间组织大型插件

默认情况下，插件将其所有 Scout 测试直接保留在 Scout 根目录下 (test/scout/{ui,api}/)。大型插件可以将测试归组到命名空间中（以功能区域命名的单层子目录）

		your-plugin/
└── test/
    └── scout/
        ├── detection_engine/
        │   ├── ui/
        │   └── api/
        ├── entity_analytics/
        │   └── ui/
        └── common/
		
	

命名空间
命名空间
共享代码（可选，保留名称）

命名空间保留了你原本会放在 Scout 根目录下的相同布局，只是深了一层，并拥有自己的 Playwright 配置、夹具 (fixtures) 和测试（例如 test/scout/<namespace>/ui/playwright.config.ts）。

为什么要使用命名空间？

范围化所有权：在 .github/CODEOWNERS 中将每个区域分配给负责它的团队，以便故障信息能传达给维护该功能的较小团队。
运行特定的子集：将 Scout 指向单个命名空间的配置，以仅运行（或重新运行）该区域的测试，而不是整个插件的套件。
在 CI 中独立运行：每个命名空间都被发现为自己的配置，因此选择性测试和 CI 报告是按区域划分的，而所有命名空间仍然共享相同的服务器配置。

生成命名空间

将 --namespace 传递给 Scout CLI

		node scripts/scout.js generate \
  --path x-pack/solutions/security/plugins/security_solution \
  --namespace detection_engine
		
	

在交互模式下，如果插件已经使用了命名空间，生成器会列出现有的命名空间，以便你可以选择一个或创建一个新的。生成脚手架后，它会提醒你在 .github/CODEOWNERS 中设置命名空间所有者。

		/x-pack/solutions/security/plugins/security_solution/test/scout/detection_engine/ @elastic/<team>
		
	

规则

重要提示

仅限一级：使用 test/scout/<namespace>/{ui,api}/（不支持更深层的嵌套，如 .../<area>/<sub-area>/{ui,api}/）。
不要混合布局：Scout 根目录要么完全是根级 (test/scout/{ui,api}/)，要么完全基于命名空间。混合使用会导致构建失败。要在现有插件中采用命名空间，请先将根级测试迁移到命名空间中。
命名：以小写字母开头，且仅使用小写字母、数字和下划线。ui、api、.meta 和 common 是保留名称（common 是一个普通的共享工具目录，没有 Playwright 配置）。