测试

Kibana 主要使用 Jest 进行单元测试。每个插件或包都定义了一个 jest.config.js，它扩展了 由 @kbn/test 包提供的预设。除非您打算运行项目中的所有单元测试，否则为要测试的插件或包提供 Jest 配置文件是最有效的。

yarn jest --config src/plugins/dashboard/jest.config.js

有一个脚本可用于在整个存储库中导航时提供更好的测试用户体验。要运行当前工作目录中的测试，请使用 yarn test:jest。与 Jest CLI 一样，您还可以提供路径以确定要运行的测试。

kibana/src/plugins/dashboard/server$ yarn test:jest #or
kibana/src/plugins/dashboard$ yarn test:jest server #or
kibana$ yarn test:jest src/plugins/dashboard/server

提供给 test:jest 的任何其他选项都将传递给 Jest CLI，并且始终会输出生成的 Jest 命令。

kibana/src/plugins/dashboard/server$ yarn test:jest --coverage

# is equivalent to

yarn jest --coverage --verbose --config /home/tyler/elastic/kibana/src/plugins/dashboard/jest.config.js server

您可以为单个插件生成代码覆盖率报告。

yarn jest --coverage --config src/plugins/console/jest.config.js

Html 报告位于 target/kibana-coverage/jest/path/to/plugin 中

查看功能测试，了解有关如何为 Kibana 核心和插件运行和开发功能测试的更多信息。

您还可以查看 Scripts README.md，了解有关使用我们提供的 node 脚本来构建 Kibana、运行集成测试以及在您开发时启动 Kibana 和 Elasticsearch 的更多信息。

我们使用功能测试来确保 Kibana UI 按预期工作。它通过自动化用户交互来取代数小时的手动测试。为了更好地控制我们的功能测试环境，并使其更易于插件作者访问，Kibana 使用了一个名为 FunctionalTestRunner 的工具。

FunctionalTestRunner (FTR) 非常简单，其大部分功能都来自其配置文件。Kibana 存储库包含许多 FTR 配置文件，这些文件对 Kibana 服务器或 Elasticsearch 使用略有不同的配置，具有不同的测试文件，并且可能还有其他配置差异。FTR 配置文件根据测试区域和分发类型在清单文件中组织： 无服务器： - ftr_base_serverless_configs.yml - ftr_oblt_serverless_configs.yml - ftr_security_serverless_configs.yml - ftr_search_serverless_configs.yml 有状态： - ftr_platform_stateful_configs.yml - ftr_oblt_stateful_configs.yml - ftr_security_stateful_configs.yml - ftr_search_stateful_configs.yml 如果您在 Kibana 存储库之外编写插件，您将拥有自己的配置文件。有关更多信息，请参阅Kibana 存储库之外的插件的功能测试。

根据您的目标，有三种运行测试的方法

在没有任何参数的情况下运行时，FunctionalTestRunner 会自动加载标准位置的配置，但是您可以使用 --config 标志覆盖该行为。使用多个 --config 参数列出配置。

还有 --bail 和 --grep 的命令行标志，它们的行为与它们的 mocha 对应项相同。例如，使用 --grep=foo 仅运行与正则表达式匹配的测试。

也可以使用 --quiet、--debug 或 --verbose 标志自定义日志记录。

还有 --include 之类的选项，仅运行单个文件或一组文件中定义的测试。

运行 node scripts/functional_test_runner --help 以查看所有可用选项。

测试是用 mocha 编写的，使用 @kbn/expect 进行断言。

我们使用 WebDriver 协议 在 Chrome 和 Firefox 中运行测试，并借助 chromedriver 和 geckodriver。当 FunctionalTestRunner 启动时，远程服务会创建一个新的 webdriver 会话，该会话将启动驱动程序和一个精简的浏览器实例。我们使用 browser 服务和 webElementWrapper 类来包装 Webdriver API。

FunctionalTestRunner 使用 babel 自动转换功能测试，以便测试可以使用与 Kibana 源代码相同的 ECMAScript 功能。请参阅 STYLEGUIDE.mdx。

提供程序

由 FunctionalTestRunner 运行的代码包装在一个函数中，以便可以通过配置文件传递它并进行参数化。任何这些 Provider 函数都可以是异步的，并且应该返回/解析为它们要提供的值。Provider 函数将始终使用单个参数调用：提供程序 API（请参阅Provider API 部分）。

配置提供程序

// config and test files use `export default`
export default function (/* { providerAPI } */) {
  return {
    // ...
  }
}

// on CI test suite will be run twice: in Chrome and Firefox
describe('My Cross-browser Test Suite', function () {
  this.tags('includeFirefox');

  it('My First Test');
}

如果测试不适用于 Firefox，请分配 skipFirefox 标签。

要在本地的 Firefox 上运行测试，请使用 config.firefox.js

node scripts/functional_test_runner --config test/functional/config.firefox.js

测试应在正面的安全边界条件下运行，这意味着它们应使用所需的最小权限（和文档记录）运行，而不是以超级用户身份运行。这可以防止出现意外需要额外权限才能执行相同操作的回归类型。

功能 UI 测试现在默认使用名为 test_user 的用户登录，并且可以在不登录和退出的情况下动态更改此用户的角色。

为了实现这一点，引入了一个名为 createTestUserService 的新服务（请参阅 packages/kbn-ftr-common-functional-ui-services/services/security/test_user.ts）。此测试用户服务的目的是创建测试配置文件中定义的角色，并设置 setRoles() 或 restoreDefaults()。

以下是如何设置角色的示例，如下所示

await security.testUser.setRoles(['kibana_user', 'kibana_date_nanos']);

在这里，我们将 test_user 设置为具有 kibana_user 角色，并且具有对特定数据索引 (kibana_date_nanos) 的角色访问权限。

测试通常应在 before() 中设置 setRoles()，并在 after() 中设置 restoreDefaults()。

此带注释的示例文件显示了每个测试套件使用的基本结构。它首先导入 @kbn/expect 并定义其默认导出：一个匿名的测试提供程序。然后，测试提供程序为 getService() 和 getPageObjects() 函数解构 Provider API。它使用这些函数来收集此套件的依赖项。测试文件的其余部分对于 mocha.js 用户来说看起来很正常。describe()、it()、before() 以及其他函数用于定义通过服务和 PageObject 类型的对象来自动化浏览器的套件。

import expect from '@kbn/expect';
// test files must `export default` a function that defines a test suite
export default function ({ getService, getPageObject }) {

  // most test files will start off by loading some services
  const retry = getService('retry');
  const testSubjects = getService('testSubjects');
  const esArchiver = getService('esArchiver');
  const kibanaServer = getService('kibanaServer');

  // for historical reasons, PageObjects are loaded in a single API call
  // and returned on an object with a key/value for each requested PageObject
  const PageObjects = getPageObjects(['common', 'visualize']);

  // every file must define a top-level suite before defining hooks/tests
  describe('My Test Suite', () => {

    // most suites start with a before hook that navigates to a specific
    // app/page and restores some archives into {es} with esArchiver
    before(async () => {
      await Promise.all([
        // start by clearing Saved Objects from the .kibana index
        await kibanaServer.savedObjects.cleanStandardList();
        // load some basic log data only if the index doesn't exist
        esArchiver.loadIfNeeded('test/functional/fixtures/es_archiver/makelogs')
      ]);
      // go to the page described by `apps.visualize` in the config
      await PageObjects.common.navigateTo('visualize');
    });

    // right after the before() hook definition, add the teardown steps
    // that will tidy up {es} for other test suites
    after(async () => {
      // we clear Kibana Saved Objects but not the makelogs
      // archive because we don't make any changes to it, and subsequent
      // suites could use it if they call `.loadIfNeeded()`.
      await kibanaServer.savedObjects.cleanStandardList();
    });

    // This series of tests illustrate how tests generally verify
    // one step of a larger process and then move on to the next in
    // a new test, each step building on top of the previous
    it('Vis Listing Page is empty');
    it('Create a new vis');
    it('Shows new vis in listing page');
    it('Opens the saved vis');
    it('Respects time filter changes');
    it(...
  });

}

所有提供程序的第一个也是唯一的参数是 Provider API 对象。此对象可用于加载服务/页面对象和配置/测试文件。

在配置文件中，API 具有以下属性

在服务和 PageObject 提供程序中，API 为

在测试提供程序中，API 与服务提供程序 API 完全相同，但有一个附加方法

FunctionalTestRunner 附带三个内置服务

Kibana 功能测试定义了测试使用的大部分实际功能。

可以在此处找到功能测试中使用的所有服务列表：test/functional/services

服务是有意为通用的。它们可以是字面上的任何东西（甚至什么都不是）。某些服务具有用于与特定类型 UI 元素（如 pointSeriesVis）交互的帮助程序，而另一些服务则更基础，如 log 或 config。当您想在可重用包中提供某些功能时，请考虑创建自定义服务。

要创建自定义服务 somethingUseful

每个 PageObject 的目的都非常不言自明。可视化 PageObject 提供了用于与可视化应用程序交互的帮助程序，仪表板对于仪表板应用程序来说是相同的，依此类推。

一个例外是“common” PageObject。作为 intern 实现的遗留问题，“common” PageObject 是跨页面有用的帮助程序集合。既然我们有了可共享的服务，并且这些服务可以与其他 FunctionalTestRunner 配置共享，我们将继续将功能从 common PageObject 移到服务中。

请将新方法添加到现有或新服务，而不是进一步扩展 CommonPage 类。

请记住，您不能在文件中运行单个测试（it 块），因为需要按顺序运行整个 describe。一个文件中应该只有一个顶级 describe。

另一个需要注意的重要问题是通过注意时间来编写稳定的测试。 remote 上的所有方法都是异步运行的。最好编写交互，等待 UI 上出现更改后再进行下一步操作。

例如，与其编写一个简单地单击按钮的交互，不如编写一个具有更高层次目标的交互

错误示例：PageObjects.app.clickButton()

class AppPage {
  // what can people who call this method expect from the
  // UI after the promise resolves? Since the reaction to most
  // clicks is asynchronous the behavior is dependent on timing
  // and likely to cause test that fail unexpectedly
  async clickButton () {
    await testSubjects.click(‘menuButton’);
  }
}

正确示例：PageObjects.app.openMenu()

class AppPage {
  // unlike `clickButton()`, callers of `openMenu()` know
  // the state that the UI will be in before they move on to
  // the next step
  async openMenu () {
    await testSubjects.click(‘menuButton’);
    await testSubjects.exists(‘menu’);
  }
}

以这种方式编写可以确保您的测试时间不会出现不稳定的情况，或者基于交互后 UI 更新的假设。

从命令行运行

node --inspect-brk scripts/functional_test_runner

这将打印出一个 URL，您可以在 Chrome 中访问该 URL 并调试浏览器中的功能测试。

您还可以通过使用 --debug 或 --verbose 标志运行 FunctionalTestRunner 在终端中查看其他日志。 使用测试中的语句添加更多日志，例如

// load the log service
const log = getService(‘log’);

// log.debug only writes when using the `--debug` or `--verbose` flag.
log.debug(‘done clicking menu’);

在具有独立显卡的机器上的 macOS 用户可以通过更改终端模拟器的 GPU 设置来显著提高测试速度（高达 2 倍）。在 iTerm2 中：* 打开首选项（Command + ,） * 在“常规”选项卡中，“魔术”部分下，确保选中“GPU 渲染” * 打开“高级 GPU 设置…” * 取消选中“优先使用集成显卡而不是独立显卡”选项 * 重启 iTerm

如果您的功能测试不稳定，那么运营团队可能会跳过它们，并要求您在再次启用它们之前使其不那么不稳定。此过程通常包括查看相关 Github 问题中记录的失败情况，并查找需要在测试中某个时刻等待的不正确的假设或条件。为了确定您的更改是否降低了测试失败的频率，您可以在不稳定测试运行器中运行测试。此工具最多运行特定 ciGroup 的 500 次执行。要启动不稳定测试运行器的构建，请使用您的更改创建一个 PR，然后访问 https://ci-stats.kibana.dev/trigger_flaky_test_runner，选择您的 PR，选择您的测试所在的 CI 组，然后触发构建。

这将带您到 Buildkite，您的构建将在其中运行，并告诉您是否在任何执行中失败。

一个不稳定的测试可能只在 1000 次运行中失败一次，因此请记住这一点，并确保您使用足够的执行次数来真正证明测试不再不稳定。

Kibana 使用 Jest 进行单元测试。

Jest 测试存储在与源代码文件相同的目录中，后缀为 .test.{js,mjs,ts,tsx}。

每个插件和包都包含自己的 jest.config.js 文件来定义其根目录，以及对 @kbn/test 提供的 jest 预设的任何覆盖。在处理单个插件或包时，您会发现运行 Jest 时提供配置文件会更有效。

yarn jest --config src/plugins/discover/jest.config.js

为了编写这些测试，您需要注意两件事。第一个是 jest.mock 和 jest.doMock 之间的区别，第二个是我们的 jest 模拟文件模式。由于我们使用 babel-jest 运行 js 和 ts 测试文件，因此两种技术都是必需的，特别是对于在 Typescript 中实现的测试，以利用自动类型推断功能。

这两种方法本质上是相同的，但是 jest.mock 调用将被提升到文件顶部，并且只能引用以 mock 为前缀的变量。另一方面，jest.doMock 不会被提升，并且可以引用我们想要的几乎任何变量，但是我们必须确保这些引用的变量在我们需要的时刻实例化，这使我们进入下一节，我们将讨论我们的 jest 模拟文件模式。

特别是在 typescript 中，在单元测试中非常常见的是 jest.doMock 调用，该调用引用例如导入的类型。执行此操作将引发任何错误，但是测试将失败。原因在于，尽管 jest.doMock 不会被 babel-jest 提升，但是我们引用的类型的导入将被提升到顶部，并且在我们调用该函数时，该变量将不会被定义。

为了防止这种情况发生，我们制定了一项协议，应遵循该协议

标准的 yarn test 任务运行多个子任务，可能需要几分钟才能完成，这使得调试失败非常痛苦。为了减轻痛苦，专门的任务提供了运行测试的替代方法。

您还可以添加 --debug 选项，以便使用 --inspect-brk 标志运行 node。您需要连接一个远程调试器，例如 node-inspector，才能在此模式下继续。

即使在使用 Kibana 插件生成器 时，我们也没有强制要求对插件进行单元测试的方法。请自行设置并使用您选择的工具。如果该插件将位于 Kibana 代码库中，则必须使用 Jest。

要编写辅助功能测试，请使用提供的辅助功能服务 getService('a11y')。辅助功能测试的编写非常简单，因为 axe 完成了大部分繁重的工作。导航到您需要测试的 UI，然后从先前导入的服务中调用 testAppSnapshot();，以确保 axe 未发现任何故障。浏览 UI 的每个部分以获得最佳覆盖率。

一个示例测试可能如下所示

export default function ({ getService, getPageObjects }) {
  const { common, home } = getPageObjects(['common', 'home']);
  const a11y = getService('a11y'); /* this is the wrapping service around axe */

  describe('Kibana Home', () => {
    before(async () => {
      await common.navigateToApp('home'); /* navigates to the page we want to test */
    });

    it('Kibana Home view', async () => {
      await retry.waitFor(
        'home page visible',
        async () => await testSubjects.exists('homeApp')
      ); /* confirm you're on the correct page and that it's loaded */
      await a11y.testAppSnapshot(); /* this expects that there are no failures found by axe */
    });

    /**
     * If these tests were added by our QA team, tests that fail that require significant app code
     * changes to be fixed will be skipped with a corresponding issue label with more info
     */
    // Skipped due to https://github.com/elastic/kibana/issues/99999
    it.skip('all plugins view page meets a11y requirements', async () => {
      await home.clickAllKibanaPlugins();
      await a11y.testAppSnapshot();
    });

    /**
     * Testing all the versions and different views of of a page is important to get good
     * coverage. Things like empty states, different license levels, different permissions, and
     * loaded data can all significantly change the UI which necessitates their own test.
     */
    it('Add Kibana sample data page', async () => {
      await common.navigateToUrl('home', '/tutorial_directory/sampleData', {
        useActualUrl: true,
      });
      await a11y.testAppSnapshot();
    });
  });
}

1)    Dashboard
       create dashboard button:

      Error: a11y report:

 VIOLATION
   [aria-hidden-focus]: Ensures aria-hidden elements do not contain focusable elements
     Help: https://dequeuniversity.com/rules/axe/3.5/aria-hidden-focus?application=axeAPI
     Elements:
       - <span aria-hidden="true"><button type="button">Submit</button></span>
       at Accessibility.testAxeReport (test/accessibility/services/a11y/a11y.ts:90:15)
       at Accessibility.testAppSnapshot (test/accessibility/services/a11y/a11y.ts:58:18)
       at process._tickCallback (internal/process/next_tick.js:68:7)

打包测试使用 Vagrant 虚拟机作为主机，并使用 Ansible 进行配置和断言。Kibana 发行版从目标文件夹复制到每个 VM 中并安装，同时安装所需的依赖项。

# Build distributions
node scripts/build --all-platforms --debug

cd test/package

# Setup virtual machine and networking
vagrant up <hostname> --no-provision

# Install Kibana and run OS level tests
# This step can be repeated when adding new tests, it ensures machine state - installations won't run twice
vagrant provision <hostname>

# Running functional tests
node scripts/es snapshot \
  -E network.bind_host=127.0.0.1,192.168.56.1 \
  -E discovery.type=single-node \
  --license=trial
TEST_KIBANA_URL=http://elastic:changeme@<ip>:5601 \
TEST_ES_URL=http://elastic:[email protected]:9200 \
  node scripts/functional_test_runner.js --include-tag=smoke

vagrant destroy <hostname>