遵循 Fuchsia 的最佳做法。
测试必须使用 //sdk/ctf/build 中的 ctf_* 规则变体。
CTF 测试以 SDK 提供的 API 和 ABI 为目标。build 支持可确保测试仅依赖于可通过 SDK 提供的 API 元素，或已列入 CTF 许可名单使用的 API 元素。所有构建目标都必须使用 //sdk/ctf/build 中的 ctf_ 规则变体，而不是标准的 fuchsia.git 规则（即使用 ctf_fuchsia_component、ctf_executable 等）。可以在 //sdk/ctf/build/allowed_ctf_deps.gni 中找到非 SDK 代码的许可名单。如果测试作者认为需要将更多内容纳入考虑范围，则应在 CTF bug 组件中提交 bug。
测试可能依赖于通过 SDK 发布的任何内容。
取决于并非通过 SDK 发布的软件，CTF 测试更容易因 Fuchsia 平台内部构件中的不相关更改而失败。我们会根据具体情况为依赖项设置例外情况。（例如，在树之外也同样能正常工作的内部测试框架）。
使用不稳定的测试运行程序的测试必须自带测试运行程序。
使用不稳定的测试运行程序（例如 Rust 测试）的测试必须通过子软件包自带测试运行程序。如需了解详情和查看示例，请参阅 CTF 贡献指南。
测试不应具有不稳定的依赖项。
测试不得依赖于可能会消失、间歇性可用或特定于并非总是运行测试的特定平台的内容。此类行为的示例包括互联网服务器和操作系统专用文件路径。
测试必须在 //sdk/ctf/tests 中实现。
如果您对此有任何疑问，请联系 fuchsia-ctf-team@google.com
应以测试作为示例来说明如何使用某个 API。
通俗来说，如果最终开发者看到测试并复制其对该 API 的使用情况，则测试作者会认为开发者将正确使用 API。测试应尽可能不依赖于未记录的、特定于应用的不变量。将来，如果未记录的使用在 Fuchsia 树之外广泛使用，我们可能需要支持不遵循推荐用法的用例。
测试不应出现超时。
应由测试基础架构强制实施超时。
测试不应是压力测试或性能测试。
我们不建议开发者向 CTF 提交压力测试或性能测试。我们将仔细检查此类测试的覆盖率值。
测试应定位平台 Surface 区域的一个元素。
CTF 测试通常直接针对平台 Surface 区域的元素。如果一项测试失败，应该可以清楚地了解平台界面区域的哪些部分被触发了，以及更改的结果是什么。根据此规则，测试中的应用逻辑量通常很小。
测试不应处于休眠状态。
休眠是导致测试不稳定的常见原因，因为各次运行之间的时间差异可能很大，具体取决于目标硬件和系统负载。我们建议开发者设置代码结构，以便在满足给定条件时发送显式信号，而不是让部分测试等待其他代码完成。
测试应避免模拟或伪造目标设备的内部状态。
CTF 旨在确保整个设备正常运行，而不是确保特定组件独立正常运行。
测试应测试边缘情况以及典型的输入和输出。
例如，整数的值为 0 和 MAXINT，以及指针值的 null 指针。
测试完成后，应能恢复系统的状态。
例如，如果某个测试需要进行系统级更改以设置文本的背景颜色，则应在测试结束时将颜色重置为原始值。这样可以防止测试相互影响。