Fuchsia 可测试性评分准则

目标

本文档的目标

Fuchsia 可测试性是一种可读性形式，专注于确保 对 Fuchsia 的更改引入了可测试和经过测试的代码。

与任何可读性流程一样，指南和标准 供审核者和评价者公开访问。本文档是 Fuchsia 与样式指南相当的可测试性，旨在确保编程语言可读性 过程。

一致地应用可测试性标准非常重要，因此 所有参与测试性测试的人员都应学习该文档（无论 审核更改或编写更改时）。

该文档的确切内容可能会随时间而变化。

测试性审核人员的目标

  • 确定是否测试更改。如果您符合以下情况，请申请Code-Review+2 并同意测试已经过测试；如果不是，请回复本邮件，说明缺少的内容。
  • 以一致的方式应用标准（本文档）。
  • 如果需要修改变更以符合标准，请提供可作为行动依据的 反馈。
  • 推广 Fuchsia 测试和可测试性。
  • 找出本文档未处理的案例并提出更改建议。
  • 坚持标准，但也灵活判断。目标是 提升测试质量并提倡测试文化。您不需要 执行精确决策算法。

您作为更改作者的目标

  • 阅读本文档，了解相关标准（您做得很好） 立即！）。
  • 尊重您的可测试性审核人员自愿担任此角色的志愿； 以适当的方式处理它们。
  • 考虑您就可通过哪些方式提高客户对您业务的信心的反馈 进行更改。

测试内容如何测试？

  • 对功能的更改应进行失败的测试， 更改。
  • 测试必须是所更改代码的本地：测试依赖项 覆盖率不会计为测试覆盖率。例如，如果“A”由 “B”和“B”包含测试，这并不涵盖“A”。 如果在“B”的测试中发现 bug，它们会间接显现， 因此更难找到“A”。同样，如果“B”（或者只是 会更改其依赖项）“A”的所有覆盖率都会丢失。
  • 测试必须自动执行（如果支持，则为 CI/CQ）。手动测试 这样就足以确保日后对代码进行更改后 （尤其是由另一位工程师编写）将执行相同的手册 测试。代码库的某些部分可能会存在例外情况，以便识别 持续面临的自动化挑战。
  • 测试必须尽量减少其外部依赖项。我们的测试基础架构 明确为每个测试预配特定资源 访问的资源远不止预配的那些资源。资源示例 包括硬件、CPU、内存、永久性存储、网络、 设备、预留网络端口和系统服务。稳定性和 未明确为测试预配的资源的可用性 因此访问此类资源的测试本身就是 不稳定和 / 或难以重现。测试不得访问外部 测试基础架构无法控制的资源。例如， 不得访问互联网上的服务。测试应仅使用资源 必要时为该测试明确配置的内容之外的内容。对于 例如，测试可能必须访问没有测试环境的 有双打。此规则的少数例外情况适用于 和端到端测试
  • 对旧版代码的更改（早于可测试性要求的旧代码） （未得到充分测试）必须进行测试。无法靠近未经充分测试的代码 不要测试新代码的理由。未测试的旧代码不一定是旧的 和冗余，但它们可能经过实践检验并经过实践检验，而 则更易失败！
  • 您对他人代码所做的更改同样适用 可测试性要求。如果作者更改了代码 因此更值得对应用进行测试通过 作者与负责个人或团队合作， 找到测试更改的有效方法。负责该代码的个人 这些更改应该可以帮助作者实现 更改优先级

不需要测试的内容

缺少以下各项的测试范围不应阻止 正在接收 Code-Review+2。

  • 日志记录。在大多数情况下，可能不值得测试日志输出 组件。日志输出通常被其他组件视为不透明数据。 因此对日志输出的更改不太可能破坏其他 系统。但是，如果日志输出在某种程度上（例如， 其他系统可能依赖于对某些日志消息的观察，则 是否值得测试这同样适用于 插桩，例如 Tracing。这不适用于插桩 以合同形式使用时，例如可以测试 Inspect 使用情况， 应该是您期望它按预期运行（例如在 ffx inspect 或反馈报告中）。
  • 不归我们所有的代码（可信来源不在 Fuchsia 树中）。 包含从其他位置复制的源代码的更新 不具有可测试性要求。
  • 纯重构（可能完全由 自动化重构工具），例如移动文件、重命名符号或 不满足可测试性要求。有些语言可以 （例如运行时反射），因此 例外情况。
  • 生成的代码。由工具生成的更改（例如格式设置、 或生成的代码作为黄金文件签入）不具有可测试性 要求。顺便说一句，我们通常不建议 （而不是利用工具，让代码在构建时生成） 但在特殊情况下， 虚拟机。
  • 可测试性引导 -在变更准备期间 为代码引入可测试性，并且相关文档已明确记录 那么可测试性审核者可以自行斟酌并采取 IOU。
  • 手动测试 -手动测试本身通常用于 展示了难以以自动化方式测试的功能。 因此，对手动测试进行的增补或修改不需要 自动化测试不过，强烈建议您进行手动测试 与描述如何运行它们的 README.md 或 TESTING.md 文档配对。
  • 硬编码值。添加或更改硬编码值不会产生任何费用 并不一定需要测试通常，这些值会控制 不易观察，例如不公开的实现 详细信息、启发词语或“外观”更改（例如界面的背景颜色）。 对样式 assert_eq!(CONFIG_PARAM, 5); 的测试不实用 是可测试性所必需的。但是，如果贡献结果 那就是在易于观察的行为变化中， 加入针对新行为的测试。

哪些项目需要测试

如果要修复不稳定问题，请在 CQ 中测试不稳定性

如果要修复不稳定问题，请通过在 CQ 中测试不稳定性来验证修复情况。

测试不应休眠

睡眠可能会导致测试不稳定，因为睡眠时间很难控制 不同的测试环境导致这种情况的一些因素 难度是测试目标的 CPU 速度、核心数和系统配置 以及温度等环境因素。

  • 请避免如下问题：

    // Check if the callback was called.
zx_nanosleep(zx_deadline_after(ZX_MSEC(100)));
EXPECT_EQ(true, callback_happened);

  • 而应明确等待条件：

    // In callback
callback() {
    sync_completion_signal(&event_);
}

// In test
sync_completion_wait(&event_, ZX_TIME_INFINITE);
sync_completion_reset(&event_);

    此代码示例改编自 task_test.cc。

针对竞态条件的回归测试

很难针对不具有高优先级的竞态条件编写回归测试 假通过率。如果您能编写一个测试来确定性地重现问题， 就应该这么做。请参阅编写可重现的确定性测试 获取提示。否则，如果通过改进锁定功能解决了数据争用问题 架构，则可以添加线程注解作为回归测试。对于其他种族 您应尝试设计能够防止出现竞态条件的 API。

最近移除的豁免项

  • Engprod 脚本（例如 fx 命令）和关联的配置文件 不再具有可测试性豁免权。fx 必须进行集成 然后再进行后续更改外汇团队可能会批准例外情况 在咨询了可测试性审核人员之后。

临时可测试性豁免

以下各项目前不受可测试性约束，而持续性工作旨在 更改它。

  • tools/devshell/contrib 中的 Engprod 脚本以及关联的 配置除外。
  • GN 模板不容易测试。我们正在努力开发一个测试框架 。在此之前， 只能手动测试。
  • 在 C 样式的代码中，资源泄漏并不容易防止。在较长的 应重构此类代码，以使用 Rust 或现代 C++ 习语 从而减少泄露的可能性 自动检测泄漏点。
  • Gigaboot 是 //src/firmware/gigaboot 中的 UEFI 引导加载程序，早于 可测试性政策。目前还没有 为 UEFI 代码编写集成测试。隆重推出 https://fxbug.dev/42109789。授予可测试性例外情况 直到 https://fxbug.dev/42109789 得到解决。